Avaliação da Maturidade Organizacional em Gestão de ... · desafio crescente no sector do estado...

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

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

Maria da Conceição Gomes Vilas Boas iii

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

iv Maria da Conceição Gomes Vilas Boas

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

Maria da Conceição Gomes Vilas Boas v

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

vi Maria da Conceição Gomes Vilas Boas

Maria da Conceição Gomes Vilas Boas vii

Dedicatória

Aos meus pais

Abílio e Amavélia

Ao meu marido

Avelino

viii Maria da Conceição Gomes Vilas Boas

Maria da Conceição Gomes Vilas Boas ix

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.

x Maria da Conceição Gomes Vilas Boas

Maria da Conceição Gomes Vilas Boas xi

Abreviaturas

ACP Áreas Chave de Processo

AIPM Australian Internacional Project Management

CE Classificador Económico

CMM Capability Maturity Model

CMMI Capability Maturity Model Integration

COBIT Control Objectives for Information and related Technology

EDT Estrutura de Decomposição do Trabalho

EUA Estados Unidos da América

IGF Inspecção – Geral de Finanças

IGF Inspecção-Geral de Finanças

IPMA International Project Management Association

ISACA Information Systems Audit and Control Association

OE Orçamento de Estado

OPM3 Organization Project Management Maturity Model

PIB Produto Interno Bruto

PLC Project Life Cycle

PMBOK Project Management Body of Knowledge

PMI Project Management Institute

PMO Project Management Office

PMP Project Management Professional

SEI Software Engineering Institute

SI Sistema de Informação

SI/TI Sistema de Informação / Tecnologias de Informação

TI Tecnologias de Informação

TIC Tecnologias de Informação e Comunicação

UMIC Agência para a Sociedade do Conhecimento

xii Maria da Conceição Gomes Vilas Boas

Maria da Conceição Gomes Vilas Boas xiii

Lista de Figuras

Figura 1 – Desempenho dos Projectos de SI/TI – 1994 a 2004 (The Standish Group). ........................... 3

Figura 2 – Estrutura e Capítulos da Dissertação. ............................................................................................ 7

Figura 3 – Ciclo de Vida dos Projectos e Processos da Gestão de Projectos. ....................................... 21

Figura 4 – Áreas de Conhecimento da Gestão de Projectos. .................................................................... 24

Figura 5 – Sucesso do Projecto – Visão Tradicional. .................................................................................. 35

Figura 6 – Modelo de Sucesso de Projecto de Pinto e Slevin (1986). ...................................................... 36

Figura 7 – As Fases do Ciclo de Vida do Projecto e as Partes Interessadas em cada Fase. ................ 39

Figura 8 – Fases do Ciclo de Vida do Projecto, perspectiva Macro e Micro (Lim e Mohamed, 1999). ................................................................................................................................................................................. 40

Figura 9 – Sucesso da Gestão de Projecto – Extensão da Visão Tradicional. ....................................... 40

Figura 10 – Dimensão de Sucesso x Tempo (Shenhar et al., 2001). ........................................................ 41

Figura 11 – Importância Relativa das Dimensões de Sucesso x Tempo (Shenhar et al., 2001). ........ 42

Figura 12 – Importância Relativa das Dimensões de Sucesso x Incerteza Tecnológica (Shenhar et al., 2001). ................................................................................................................................................................ 42

Figura 13 – Modelo Original de DeLone e McLean para Sucesso de Projectos................................... 43

Figura 14 – Adaptação do Modelo Original de DeLone e McLean para Sucesso de Projectos. ....... 44

Figura 15 – Componentes de Sucesso do Projecto. .................................................................................... 44

Figura 16 – A Estrutura do CMM. .................................................................................................................. 58

Figura 17 – História do CMMs. ....................................................................................................................... 60

Figura 18 – Representação Contínua. ............................................................................................................. 61

Figura 19 – Representação em Estádios. ....................................................................................................... 62

Figura 20 – Princípios Básicos do CobiT. ...................................................................................................... 65

Figura 21 – Framework CobiT......................................................................................................................... 67

Figura 22 – Gráfico de Representação dos Níveis de Maturidade. .......................................................... 68

Figura 23 – Pergunta de Investigação e Ligação às Proposições. ............................................................. 80

Figura 24 – Amostra. .......................................................................................................................................... 92

Figura 25 – Serviços Integrados - Evolução da Despesa em TI por Organismo, 2005 a 2007. ........ 95

Figura 26 – Serviços e Fundos Autónomos - Evolução da Despesa em TI por Organismo, 2005 a 2007. ....................................................................................................................................................................... 96

Figura 27 – Despesa Média Anual em TI por Organismo – 2005 a 2007. ............................................. 97

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 2007. ....................................................... 98

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 2007. ........................................... 99

Figura 30 – Serviços Integrados e Serviços e Fundos Autónomos – Nível de Maturidade Organizacional em Planeamento Estratégico de TI. ................................................................................. 101

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). ............................................................................................................................................. 102

xiv Maria da Conceição Gomes Vilas Boas

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). .................................... 103

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). ...... 104

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 2007. ........................................................... 106

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). ........................................................................................................................................................... 107

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). ...................................................... 109

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). ...................................................... 110

Maria da Conceição Gomes Vilas Boas xv

Lista de Tabelas

Tabela 1 - Serviços Integrados e Serviços e Fundos Autónomos, Despesa em TI, 2005-2007. ........... 1

Tabela 2 - Top 10 das Razões do Sucesso dos Projecto de SI/TI, 2001 (The Standish Group). ........ 4

Tabela 3 – Mapeamento das Áreas de Conhecimento, Processos e Grupos de Processos. ............... 29

Tabela 4 – Críticos de sucesso de Pinto e Slevin (1986). ............................................................................ 36

Tabela 5 – Critérios de Sucesso de Turner (1993). ...................................................................................... 37

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. ...................................................................................................... 37

Tabela 7 – Cinco Principais Critérios de Sucesso (Frequência de Citações) Segundo a Percepção dos Utilizadores e dos Gestores de Projectos. ...................................................................................................... 38

Tabela 8 – Dimensões de Sucesso de Projecto, Segundo Dvir et al. (1998). ......................................... 39

Tabela 9 – Critérios de Sucesso de Projecto, Segundo Shenhar et al. (2001). ........................................ 41

Tabela 10 – Factores Críticos de Sucesso Identificados Cruzados em 63 Publicações. ...................... 48

Tabela 11 – Factores Críticos de Sucesso (Yeo, 2002). ............................................................................... 49

Tabela 12 – Elementos que Afectam, Simultaneamente, a Percepção de Sucesso e de Fracasso (Backer, Murphy e Fisher, 1983). ..................................................................................................................... 50

Tabela 13 – Elementos que Afectam a Percepção de Sucesso (Backer, Murphy e Fisher, 1983). .... 50

Tabela 14 – Elementos que Afectam a Percepção de Fracasso (Backer, Murphy e Fisher, 1983). ... 51

Tabela 15 – Evolução Histórica do Modelo de Capability Maturity Model for Software................... 55

Tabela 16 – Níveis de Maturidade do CMM. ................................................................................................ 57

Tabela 17 – Áreas Chave do Processo por Nível de Maturidade. ............................................................ 59

Tabela 18 – Comparação da Representação Contínua e Estádios ........................................................... 62

Tabela 19 – Comparação dos Níveis de Representação Continua e Estádios. ...................................... 63

Tabela 20 – Domínios vs Processos de CobiT. ............................................................................................ 66

Tabela 21 – Organismos onde a Inexistência ou Escassez de Pessoal TI tem Condicionado Negativamente o Desenvolvimento das suas Actividades. ........................................................................ 79

Tabela 22 – Recursos Humanos de TI – Variáveis e Medidas. ................................................................. 84

Tabela 23 – Despesa em SI/TI – Variáveis e Medidas. .............................................................................. 85

Tabela 24 – Maturidade em Planeamento Estratégico de TI – Variáveis e Medidas. .......................... 86

Tabela 25 – Maturidade em Gestão de Projectos – Variáveis e Medidas. .............................................. 87

Tabela 26 – O que é uma Correlação Elevada? Segundo Cohen e Holliday (1982)............................. 88

Tabela 27 – Serviços Integrados e Serviços e Fundos Autónomos – Despesa em TI, 2005 a 2007 94

Tabela 28 – Serviços Integrados e Serviços Fundos Autónomos – Recursos Humanos TI e Recursos Humanos – 2005 a 2007. ................................................................................................................. 99

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. ........................................................................................ 100

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.......................... 112

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. ......................................................... 112

xvi Maria da Conceição Gomes Vilas Boas

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. ............................................................................................. 113

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 ...................................... 113

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). ................................................................................................................................................................ 114

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. .......................................................................................... 114

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 (%). .......... 114

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 (%) ................................................. 115

Tabela 38 – Serviços Integrados - Correlação entre Maturidade em Gestão de Projectos SI/TI e Recursos Humanos TI por Recursos Humanos Globais (%). ................................................................ 115

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. ................... 115

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. ................................................................................................ 116

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 (%). ........... 116

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 (%). .............................................. 116

Tabela 43 – Serviços Integrados - Correlação entre Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%). .................................................................. 117

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 (%). ........... 117

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 (%). ............................................................. 117

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. .................................... 119

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. ......................................................................................... 119

Tabela 48 – Correlação entre a Percentagem a Despesa em TI e Nível de Maturidade Organizacional em Gestão de Projectos SI/TI. ......................................................................................... 120

Tabela 49 – Escalonamento da Despesa Média Anual vs Número de Entidades .............................. 122

Tabela 50 – Escalonamento da % de Recursos Humanos de TI vs Número de Entidades ............ 122

Tabela 51 – Tipos de Estudos de Casos (Yin, 1989). ................................................................................ 137

Tabela 52 – Critérios de Avaliação de Documentos (Scott, 1990). ........................................................ 138

Tabela 53 – Unidades de Análise ................................................................................................................... 141

Tabela 54 – Recursos Humanos – 2005 a 2007. ........................................................................................ 161

Maria da Conceição Gomes Vilas Boas xvii

Tabela 55 – Recursos Humanos de TI – 2005 a 2007. ............................................................................. 162

Tabela 56 – Despesa Global – 2005 a 2007. ............................................................................................... 163

Tabela 57 – Despesa em TI – 2005 a 2007. ................................................................................................ 164

Tabela 58 – Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI). ............................................................................................................................................. 165

Tabela 59 – Nível de Maturidade dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos). ........................................................................................................................................................... 166

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). ............................................................................................................................................. 167

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). .................................... 168

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). ......................................................... 169

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). ............................................................................................................................................................................... 170

Tabela 64 – Serviços Integrados - Correlação entre Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos). ...................................................... 171

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). .............................................. 172

xviii Maria da Conceição Gomes Vilas Boas

Maria da Conceição Gomes Vilas Boas xix

Í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 ............................................................................................................. 1

1.1. Contexto e Motivação ......................................................................................................... 1

1.2. Objecto de Estudo .............................................................................................................. 5

1.3. Metodologia .......................................................................................................................... 6

1.4. Organização da Dissertação ............................................................................................... 6

2. Gestão de Projectos ............................................................................................... 9

2.1. Enquadramento de Gestão de Projectos ....................................................................... 10

2.1.1. O que é um Projecto?.............................................................................................. 10

2.1.2. Quais os Stakeholders do Projecto? ...................................................................... 11

2.1.3. O que é um Portfolio, Programa e Subprojecto? ................................................... 12

2.1.4. O que é a Gestão de Projectos? ............................................................................. 13

2.1.5. Quais as Capacidades Requeridas a um Gestor de Projecto? ............................ 15

2.1.6. O que é um Escritório de Gestão de Projectos? ................................................. 17

2.2. Selecção e Avaliação de Projectos ................................................................................... 18

2.2.1. Selecção Estratégica de Projectos .......................................................................... 18

2.2.2. Avaliação Financeira e Técnica do Projecto ........................................................ 19

2.3. Metodologia de Gestão de Projectos .............................................................................. 19

2.3.1. PMBOK Guide 2004 .............................................................................................. 19

2.3.2. Ciclo de Vida da Gestão de Projectos .................................................................. 20

2.3.3. Processo da Gestão de Projectos .......................................................................... 21

2.3.4. Áreas de Conhecimento da Gestão de Projecto ................................................. 24

xx Maria da Conceição Gomes Vilas Boas

2.4. Mapeamento do Processo de Gestão de Projectos ...................................................... 29

2.5. Síntese ................................................................................................................................. 30

3. Avaliação de Projectos de SI/TI ......................................................................... 33

3.1. Conceitos ............................................................................................................................ 33

3.1.1. Sistema e Tecnologia de Informação ................................................................... 33

3.1.2. Critério e Factor de Sucesso .................................................................................. 34

3.2. Avaliação de Projectos – Critérios e Factores de Sucesso .......................................... 34

3.2.1. Critérios de Sucesso ................................................................................................ 35

3.2.2. Factores Críticos de Sucesso ................................................................................. 44

3.3. Síntese ................................................................................................................................. 51

4. Modelos de Avaliação da Maturidade Organizacional ...................................... 53

4.1. Enquadramento ................................................................................................................. 53

4.2. Capability Maturity Model (CMM) ................................................................................. 55

4.2.1. Introdução ................................................................................................................ 55

4.2.2. Organizações Imaturas Vs Organizações Maduras ............................................ 55

4.2.3. Conceitos Fundamentais Associados ao CMM .................................................. 56

4.2.4. Níveis de Maturidade e Áreas Chave de Processo ............................................. 57

4.3. Capability Maturity Model Integration (CMMI) ........................................................... 60

4.3.1. Introdução ao Capability Maturity Model Integration ....................................... 60

4.3.2. Representações do CMMI ..................................................................................... 61

4.3.3. Níveis de maturidade .............................................................................................. 63

4.4. Control Objectives for Information and related Technologies (CobiT) .................. 63

4.4.1. Enquadramento ....................................................................................................... 63

4.4.2. Conceitos e Definições Fundamentais para a Framework CobiT ................... 64

4.4.3. Princípios da Framework CobiT ........................................................................... 65

4.4.4. Modelo de Maturidade ........................................................................................... 68

4.4.5. Planeamento Estratégico de TI e Gestão de Projectos ..................................... 69

4.5. Avaliação da Maturidade - Síntese .................................................................................. 75

5. O Problema ......................................................................................................... 77

5.1. Problema de Investigação ................................................................................................ 79

5.2. Pergunta de Investigação e Proposições ........................................................................ 79

5.3. Tipo de Estudo .................................................................................................................. 80

6. Metodologia de Investigação ............................................................................... 81

Maria da Conceição Gomes Vilas Boas xxi

6.1. Escolha das Unidade de Análise ...................................................................................... 83

6.2. Instrumento de Recolha de Informação ........................................................................ 83

6.2.1. Recursos Humanos de TI ....................................................................................... 84

6.2.2. Despesa em SI/TI ................................................................................................... 84

6.2.3. Maturidade Organizacional em Planeamento Estratégico de TI e Gestão de Projectos de SI/TI ................................................................................................................... 85

6.2.4. Correlação entre as Variáveis do Estudo ............................................................. 88

6.3. Estratégia de Recolha de Dados ...................................................................................... 89

6.4. Recolha de Dados e Análise de Dados ........................................................................... 89

7. Estudo de Caso .................................................................................................... 91

7.1. Características da Amostra ............................................................................................... 91

7.2. Resultados da Análise ........................................................................................................ 93

7.2.1. Características da Despesa em TI e Recursos Humanos ................................... 94

7.2.2. Características da Maturidade Organizacional ................................................... 100

7.2.3. Análise das Proposições ........................................................................................ 112

7.3. Síntese dos Resultados do Estudo de Caso ................................................................. 117

8. Conclusões e Trabalho Futuro ........................................................................... 121

8.1. Conclusões ........................................................................................................................ 121

8.2. Limitações e Constrangimentos ao Trabalho .............................................................. 124

8.3. Contributos ....................................................................................................................... 124

8.4. Trabalho Futuro ............................................................................................................... 124

Referências ................................................................................................................... 127

Anexo A: O Método de Estudo de Caso ................................................................. 133

A.1 Definição do Método de Estudo de Caso ................................................................... 133

A.2 O Uso do Método de Estudo de Caso ......................................................................... 134

A.3 O Plano de Estudo de Caso ........................................................................................... 135

A.4 Critérios para Avaliar a Qualidade do Estudo de Caso .............................................. 136

A.5 Tipos de Estudo de Caso ............................................................................................... 137

A.6 O Protocolo do Estudo de Caso ................................................................................... 137

A.7 Condução do Estudo de Caso ....................................................................................... 138

Anexo B: Unidades de Análise ................................................................................. 141

Anexo C: Análise do Classificador Económico das Despesas SI/TI ..................... 143

xxii Maria da Conceição Gomes Vilas Boas

Anexo D: Questionário ............................................................................................ 147

Anexo E: Respostas ao Questionário ...................................................................... 159

E.1 Recursos Humanos – 2005 A 2007 .............................................................................. 161

E.2 Recursos Humanos de TI – 2005 A 2007 ................................................................... 162

E.3 Despesa Global – 2005 a 2007 ...................................................................................... 163

E.4 Despesa em TI – 2005 a 2007 ....................................................................................... 164

E.5 Planeamento Estratégico de TI ..................................................................................... 165

E.6 Gestão de Projectos ........................................................................................................ 166

E.7 Correlação entre os Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI) ........................................................................................................................ 167

E.8 Correlação entre os Objectivos de Controlo do Processo PO10 (Gestão de Projectos) ...................................................................................................................................... 170

Maria da Conceição Gomes Vilas Boas 1

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/TI1) 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)

2005 221.146.745,89 201.890.492,13 423.037.238,02

2006 220.674.589,25 209.219.267,55 429.893.856,80

2007 242.731.630,23 201.533.525,02 444.265.155,25

Média 228.184.321,79 204.214.428,23 432.398.750,02

% 52,8% 47,2% 100%

Tabela 1 - Serviços Integrados e Serviços e Fundos Autónomos, Despesa em TI, 2005-2007. Fonte: adaptado do relatório nº 1290/2008, da IGF.

1 Ver definição de SI/TI no ponto 3.1.1.

2 Maria da Conceição Gomes Vilas Boas

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ções2 com um valor médio anual aproximado de 200,65 milhões de euros (46,40%); a hardware3 aproximadamente 122,55 milhões de euros (28,34%); a software informático4 aproximadamente 97,51 milhões de euros (22,55%); a locação de material de informática5 aproximadamente 11,28 milhões de euros (2,61%) e material de informática - locação financeira6 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: 02.02.09 - «Comunicações».

3 «Despesa em hardware» compreende o somatório das despesas classificadas nas seguintes rubricas com a CE: 07.01.07 - «Equipamento de informática»; 07.01.09.Y0.A0 - «Equipamento administrativo - hardware de comunicações»; 07.01.10.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: 07.01.08 - «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: 02.02.05 - «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: 07.02.06 - «Material de Informática - locação financeira».


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 3.2.1. 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.

1994 1996 1998 2000 2004

Sucesso (“Successed”) 16% 27% 26% 28% 29%

Insucesso (“Failed”) 31% 40% 28% 23% 18%

Sucesso parcial (“Challenged”) 53% 33% 46% 49% 53%

0%

10%

20%

30%

40%

50%

60%


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 3.2.2.

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


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.

1.2. 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 (%).


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.

1.3. 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.

1.4. 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;


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.

Figura 2 – Estrutura e Capítulos da Dissertação.

Fonte: Autor.

Capítulo 1: Introdução

Parte 1: Estado da Arte - Revisão da Literatura

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

Parte 2: Problema e Medodologia de

Investigação

Capítulo 5: O Problema

Capítulo 6: Metodologia

de Investigação

Parte 3: Estudos e Conclusões

Capítulo 7: Estudo de

Caso

Capítulo 8: Conclusões e Trabalho

Futuro


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 Knowledge7).

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 99-001-2000.


2.1. Enquadramento de Gestão de Projectos

2.1.1. 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 joint-venture 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].


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 complexa8, 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.

2.1.2. 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 sub-projects, many deliverables, etc. would combine to form a complex project. A complex project still maintains the characterist ic of a project by having a definite beginning and end, and producing a unique product or service, with a defined scope‖[WWPMM, 2002].


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).

2.1.3. 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].


2.1.4. 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, afirmando-se 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 2.3.3.

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.


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 Critico9 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.


manter em equilibro o âmbito, custo, prazo e qualidade.

2.1.5. 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].


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 walkthroughs11 (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].


2.1.6. 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;


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.

2.2. Selecção e Avaliação de Projectos

2.2.1. 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;


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].

2.2.2. Avaliação Financeira e Técnica do Projecto

―A justificação do projecto é obtida pela realização de um estudo de exequibilidade12, 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.

2.3. Metodologia de Gestão de Projectos

2.3.1. 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].


– 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].

2.3.2. 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 (entregas13). 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.


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.

2.3.3. Processo da Gestão de Projectos

Segundo o PMI a gestão de cada projecto passa por 5 grupos de processos14 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.


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:

2.3.3.1. 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.

2.3.3.2. 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.


À 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.

2.3.3.3. 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.

2.3.3.4. 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


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.

2.3.3.5. 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).

2.3.4. Á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.

Figura 4 – Áreas de Conhecimento da Gestão de Projectos.

Fonte: Autor.

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


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.

2.3.4.1. 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.

2.3.4.2. 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;


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.

2.3.4.3. 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.

2.3.4.4. 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.

2.3.4.5. 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;


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.

2.3.4.6. 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.

2.3.4.7. 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.

2.3.4.8. 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;


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.

2.3.4.9. 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.


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 2004.

Áreas de Conhecimentos

Iniciação Planeamento Execução Monitorização

e controlo Encerramento

Gestão da Integração

- Criar o Termo de Abertura - Desenvolver a descrição do âmbito

- Desenvolver o plano de gestão do projecto

- Dirigir e gerir a execução do projecto

- Monitorizar e controlar o trabalho do projecto

- Encerrar o projecto

Gestão do Âmbito

- Planear e definir o âmbito do projecto - Criar a EDT

- Verificar e controlar o âmbito do projecto

Gestão do Prazo

- Definir e sequenciar as actividades - Estimar os recursos - Estimar a duração das actividades - Desenvolver o cronograma do projecto

- Controlar o cronograma do projecto

Gestão do Custo - Estimar e

orçamentar o custo do projecto

- Controlar o custo do projecto

Gestão da Qualidade

- Planear a qualidade

- Executar a garantia da qualidade

- Realizar o controlo da qualidade

Gestão do Recursos Humanos

- Planear os recursos humanos

- Recrutar a equipa de projecto - Desenvolver a equipa de projecto

- Gerir a equipa de projecto

Gestão da Comunicação

- Planear as comunicações

- Distribuir a informação

- Relatar o desempenho do projecto - Gerir os stakeholders

Gestão do Risco

- 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

- Monitorizar e controlar os riscos do projecto

Gestão das aquisições

- Planear as compras - Planear a contratações

- Pedir proposta e seleccionar fornecedores

- Administrar os contratos

- Encerrar os contratos

Tabela 3 – Mapeamento das Áreas de Conhecimento, Processos e Grupos de Processos.

Fonte: Adaptação do PMBoK, 2004.


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 2.1.4 e 2.3.3.

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


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.


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‖.

3.1. Conceitos

3.1.1. 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


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.‖.

3.1.2. 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].

3.2. 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


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.

3.2.1. 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].

1973. 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.

1983. Backer, Murphy e Fisher (1983), citado por Agarwal et al. (2006), definem o sucesso do projecto:


“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.

1986. 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 Factores Externos

Custo – grau de cumprimento do orçamento inicial do projecto.

Uso – se o projecto é usado de acordo com sua proposta original.

Prazo – cumprimento dos prazos inicialmente estabelecidos.

Satisfação – a satisfação com o processo pelo qual o projecto está sendo foi realizado.

Desempenho técnico – grau em que o projecto atende às especificações técnicas implícitas e explícitas.

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).

1987. 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;


No caso do projecto cancelado, este é cancelado pelas razões básicas e o projecto é terminado com eficiência.

1988. 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).

1990. 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.

1993. 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, 1998.

1995 e 1998. 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 %

Todos os projectos

Atender aos requisitos dos utilizadores 96 Atender aos requisitos dos utilizadores 82

Satisfação dos utilizadores 71 Cumprimento do orçamento 72

Cumprimento do orçamento 67 Cumprimento dos prazos 69

Projectos de Sucesso


Satisfação dos utilizadores 71 Sucesso comercial 71

Cumprimento do orçamento 71 Cumprimento das metas de qualidade 67

Projectos

Fracassados

Atender aos requisitos dos utilizadores 100 Cumprimento do orçamento 83

Atender ao seu propósito 100 Cumprimento dos prazos 78

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.



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 %

Todos os projectos


Satisfação dos utilizadores 69 Cumprimento do orçamento 71


Cumprimento do orçamento 62 Sucesso comercial 60

Cumprimento dos prazos 58 Atender ao seu propósito 60

Projectos de Sucesso


Satisfação dos utilizadores 71 Sucesso comercial 71

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

Projectos Fracassados

Atender aos requisitos dos utilizadores 100 Cumprimento do orçamento 83


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.


1996. 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.


Figura 7 – As Fases do Ciclo de Vida do Projecto e as Partes Interessadas em cada Fase.

Fonte: Munns e Bjeirmi (1996).

1998. 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 Variáveis utilizadas

Cumprimento de metas

do projecto

Especificações funcionais

Especificações técnicas

Prazo

Orçamento

Benefícios percebidos

pelo consumidor

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., 1998.

1999. 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.


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).

1999. Para Baccarini (1999, p. 25) o sucesso do projecto consiste em duas componentes distintas15, 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.


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.

2001. 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).


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


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).


Figura 12 – Importância Relativa das Dimensões de Sucesso x Incerteza Tecnológica (Shenhar et al., 2001).


2002. 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.


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, 2003.

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.


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, 2003.

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.

3.2.2. 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. 4.


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 Estudos Empíricos - Survey Estudos Empíricos –

Caso de estudo Estudos Teóricos C

Apoio da alta administração

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).

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)

39

Definição realista dos objectivos

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).

Morris (1986); Yeo (1995); Beare (1995); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003).

Hughes (1986); Tennant (1993); Harding (1995); Munns and Bjeirmi (1996); Spinelli (1997); Cicmil (1997); Glass (1998); Weir (1999); Turner (2004).

31

Plano de trabalho mantido actualizado

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).

Avots (1969); Morris (1986); Morris and Hough (1987); Martinez (1994); McGolpin and Ward (1997); Westerveld (2003).

Cleland and King (1983); Williams (1995); Spinelli (1997); McCormack (1997); Glass (1998); Turner (1999); Turner (2004).

29

Boa comunicação 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

Avots (1969); Morris (1986); McComb and smith (1991); Gowan and Mathieu (1996); Cooke-Davies (2002); Westerveld (2003).

Cleland and King (1983); Hughes (1986); Cash and Fox (1992); Hilderbrand (1996); Spinelli (1997); Turner (1999); Turner (2004).

27




Williams (1998); Clarke (1999); Thite (2000); Andersen et al. (2002); Yeo (2002).

Envolvimento dos utilizadores e clientes

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).

Morris (1986); McComb and Smith (1991); Beare (1995); Wastell and Newman (1996); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003).

Munns and Bjeirmi (1996); Cicmil (1997); Spinelli (1997); McCormack (1997); Turner (1999); Turner (2004).

24

Qualificações adequadas da equipa do projecto

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).

Morris (1986); Mccomb and Smith (1991); Martinez (1994); Willcocks and Griffiths (1994); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003).

Cash and Fox (1992); Tenant (1993); Glass (1998); Weir (1999).

20

Gestão efectiva da mudança

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)

Avots (1969); Mccomb and Smith (1991); Martinez (1994); Willcocks and Griffiths (1994); Hougham (1996); McGolpin and Ward (1997); Cooke-Davies (2002).

Cash and Fox (1992); Cicmil (1997); Weir (1999).

19

Competência do gestor do projecto

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).

Avots (1969); Morris (1986); Martinez (1994); Cannon (1994); Pinto and kharbanda (1996); Westerveld (2003).

Munns and Bjeirmi (1996); Spinelli (1997); Glass (1998); Weir (1999); Turner (2004).

19

Forte motivação comercial / conhecimentos sólidos para os projectos

Pollalis and Frieze (1993); Smart (1995); KPMG (1997); Dvir et al. (1998); Whittaker (1999); Poon and Wagner (2001); Andersen et al. (2002); Yeo (2002).

Avots (1969); Pinto and Kharbanda (1996); McGolpin and Ward (1997); Cooke-Davies (2002); Caldeira and Ward (2002); Westerveld (2003).

Munns and Bjeirmi (1996); Turner (2004).

16

Boa alocação dos recursos

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).

Morris (1986); Morris and Hough (1987); Gowan and Mathieu (1996); Caldeira and Ward (2002); Westerveld (2003).

Tennant (1993); McCormack (1997); Turner (1999); Turner (2004).

16

Boa liderança Pollalis and frieze (1993); Smart (1995); Dvier et al. (1998); Thite (2000); Andersen et al. (2002).

Morris and Hough (1987); Martinez (1994); Gowam and Mathieu (1996); Pinto and Kharbanda (1996); Caldeira and Ward (2002); Westerveld (2003).

Cash and Fox (1992); Tennant (1993); Turner (1999); Turner (2004).

15

Tecnologia comprovada e familiar

Pinto e Mantel (1990); Pollalis and Frieze (1993); Tan (1996); KPMG (1997); Dvir et al. (1998); Poon and Wagner (2001); Yeo (2002).

Morris (1986); McComb and smith (1991); Cannon (1994); Yeo (1995); Caldeira and Ward (2002).

Williams (1995); Glass (1998).

14

Cronograma Pinto e Mantel (1990); Selin Morris (1986); Morris and Cleland and King (1983); 14




realista and selin (1994); Dvir et al. (1998); Kasser and Williams (1998); Yeo (2002).

Hough (1987); McComb and Smith (1991); Westerveld (2003).

Tennant (1993); Glass (1998); Weir (1999); Turner (2004).

Gestão do risco Selin and Selin (1994); Smart (1995); KPMG (1997); Dvir et al. (1998); Whittaker (1999); Yeo (2002).

Moriris (1997); Beare (1995); Cooke-Davis (2002); Westerveld (2003).

Williams (1995); Baldry (1998); Weir (1999).

13

―Campeão‖ / Pratocionador do projecto

Yap et al. (1992); Thite (2000); Poon and Wagner (2001); Yeo (2002).

Morris (1986); Morris and Hough (1987); Martinez (1994); MCGolpin and Ward (1997); Jang and Lee (1998); Caldeira and Ward (2002).

Cash and Fox (1992); Baldry (1998)

12

Efectiva monitorização e controlo

Pollalis and Frieze (1993); Selin and Selin (1994); Dvir et al. (1998); Thite (2000); Poon and Wagner (2000).

McComb and Smith (1991); Cooke-Davies (2002); Westerveld (2003).

Cash and Fox (1992); Cicmil (1997); Weir (1999); Turner (2004).

12

Custos adequado Baker et al. (1983); Dvir et al. (1998) ; Pollalis and Frieze (1993).

Morris and Hough (1987); McComb and Smith (1991); Caldeira and Ward (2002); Westerveld (2003).

Cleland and king (1983); Tennant (1993); Glass (1998); Turner (2004).

11

Adaptação organizacional/cultural e estrutural

Pollalis and Frieze (1993); Couillard (1995); Taylor (2000); Thite (2000).

Cahnon (1994); Willcocks and Griffiths (1994); Martinez (1994); Hougham (1996); Gowan and Mathieu (1996); Cooke-Davies (2002).

10

Bom desempenho por parte dos fornecedores/construtores/consultores

Pollalis and frieze (1993); kPMG (1997); Yeo (2002).

Morris and Hough (1987); Jang and Lee (1998); Caldeira and Ward (2002); Westerveld (2003).

McCormack (1997); Glass (1997); Turner (2004).

10

Planeamento encerrado / revisto/ aceite como um possível fracasso

Dvir et al. (1998) Avots (1969); Sauer (1993); Beare (1995); Pinto and Kharbanda (1996); McGolpin and Ward (1997).

Cleland and king (1983); Munns and Bjeirmi (1996); McCormack (1997).

9

Oferta de formação

Magal e tal (1988); Yap et al. (1992); Pinto and Kharbanda (1995); Dvir et al. (1998).

Pinto and Kharbanda (1996); Caldeira and Ward (2002).

McCormack (1997) 7

A estabilidade política

Pollalis and Frieze (1993). Morris and hough (1987); Sauer (1993); Yeo (1995); Pinto and Kharbanda (1996).

Tennant (1993) 6

Escolha correcta / experiência anterior em metodologias da gestão do projecto / ferramentas

Dvier et al. (1998). Jang and lee (1998). Hughes (1986); Munns and Bjeirmi (1996); Glass (1998); Turner (2004).

6

Influência do desenvolvimento

Morris (1986); Pinto and kharbanda (1996); Caldeira and Ward (2002); Westerveld (2003).

Cleland and King (1983); Archibald (1992).

6

Experiência Yap et al. (1992); Dvir et al. Jordan et al. (1988); Sauer 5




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)

Selin and Selin (1994). Cannon (1994); Cooke-Davies (2002).

Hughes (1986)

4

Diferente ponto de vista

/apreciações

Curtis et al. (1988); Pinto and Kharbanda (1995).

Turner (2004) 3

Tabela 10 – Factores Críticos de Sucesso Identificados Cruzados em 63 Publicações.

Fonte: Fortune e White (2006).

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

1999. 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.


Factor de insucesso a ausência de um plano estratégico de TI

2002. 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

projectos de SI

Estimativas de prazos

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

Tabela 11 – Factores Críticos de Sucesso (Yeo, 2002).

Fonte: Yeo, 2002.

Factores críticos de sucesso e insucesso

1983. 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:


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:

Tabela 13 – Elementos que Afectam a Percepção de Sucesso (Backer, Murphy e Fisher, 1983).


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


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).


3.3. 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].


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.


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.

4.1. 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:


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.


4.2. Capability Maturity Model (CMM)

4.2.1. 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 do Mitre Corporation

Começa a desenvolver a estrutura de maturidade do processo que 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.

1991 SEI Publica a versão nº 1.0 do CMM para software.

1992 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.

4.2.2. 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.


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 custo-benefí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].

4.2.3. 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


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].

4.2.4. 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

Descrição

Nível 1. Inicial 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.

Nível 2. Repetível 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.

Nível 3. Definido 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.

Nível 4. Gerido 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.

Nível 5. Optimizado. 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.


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].


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 Área chave do processo

Nível 1. Inicial

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.


4.3. Capability Maturity Model Integration (CMMI)

4.3.1. 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é 1997. 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, 2006.

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 SEI16 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 15504 [CMMI, 2006].

16 Após 31 de Dezembro.


4.3.2. 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, 2006.

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


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, 2006.

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 que as organizações tenham um caminho de melhoria pré-definido e provado.

Permite uma maior visibilidade das capacidades alcançadas, em cada área individual do processo.

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.

Permite melhoria de processos diferentes, a ser realizada em diferentes taxas.

Resume a melhoria dos resultados dos processos numa forma simples e um único nível de maturidade.

Reflecte uma nova abordagem que ainda não tem dados para demonstrar os seus laços com o retorno do investimento.

Baseia-se na longa história de utilização, que inclui estudos de caso e dados que demonstram a rentabilidade do investimento.

Tabela 18 – Comparação da Representação Contínua e Estádios

Fonte: CMMI, 2006.

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 15504. 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.


4.3.3. 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, 2006.

4.4. Control Objectives for Information and related Technologies (CobiT)

4.4.1. 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 ITGI17 (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), 1999-2004;

(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].


(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, 2006.

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, 2nd edition;

• CobiT control practices, 2nd edition;

• IT Assurance Guide.

4.4.2. 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].


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].

4.4.3. 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:

Figura 20 – Princípios Básicos do CobiT.

Fonte: ITIGI, 2007. O CobiT subdivide-se em 4 domínios:

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


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 Processos

Planeamento e Organização (PO)

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

Aquisição e Implementação (AI)

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

Entrega e Suporte (DS)

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

Monitorização e Avaliação (ME)

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, 2006.

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.


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, 2007.

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.


4.4.4. 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, 2007.

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 de Maturidade

Descrição do Ambiente de Controlo

Nível 0. Inexistente

Completa inexistência do processo. A entidade não reconhece a necessidade de tratar e gerir o assunto.

Nível 1. Inicial / Ad Hoc

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.

Nível 2. Repetitivo mas intuitivo

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.

Nível 3. Definido

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


uma mera formalização das práticas existentes.

Nível 4. Mensurável

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.

Nível 5. Optimizado

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].

4.4.5. 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.

4.4.5.1. 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;


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.


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 de Controlo

Riscos

Gerir o Valor de TI

– 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

Alinhamento das TI com o Negócio

– 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

Avaliação de desempenho e capacidade actual

– 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

Plano Estratégico de TI

– 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

Planos Táctico TI

– 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

Gerir o Portfolio de TI

– 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].


4.4.5.2. 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: 10.1. 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: 10.2. 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: 10.3. 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: 10.4. 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: 10.5. 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: 10.6. 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;


Objectivo de Controlo: 10.7. 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: 10.8. 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: 10.9. 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: 10.10. 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: 10.11. 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: 10.12. 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: 10.13. 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: 10.14. 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.


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 Riscos

Framework de Gestão de Programas

– Inapropriado priorização do projecto – Desorganizada e ineficaz abordagem do programa do

projecto programas – Desalinhamento do projecto com os objectivos do

programa Framework de Gestão de Projectos

– 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

Abordagem de Gestão de Projectos

– 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 Compromisso de Stakeholder

– 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

Declaração de Âmbito de Projecto

– Incompreensão dos objectivos do projecto e exigências – Incompreensão do impacto do projecto com outros

projectos relacionados Fase Inicial do Projecto – 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

Planeamento Integrado do Projecto

– 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 Recursos do Projecto – 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

Gestão do Risco do Projecto

– Não detectados os riscos do projecto – A falta de acções para mitigar os riscos identificados

Plano de Qualidade do Projecto

– 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 Controlo das Alterações do Projecto

– A falta de controlo sobre âmbito do projecto, custo e cronograma

– Perda de foco comercial – A incapacidade de gerir recursos


Planeamento dos Métodos de Segurança

– Garantia actividades de falsas – Atrasos na acreditação e implementação

Medir, Reportar e Monitorizar o Desempenho do Projecto

– 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 Encerramento do Projecto

– 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].

4.5. 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.


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 4.4.5.

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 4.4.4.

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 4.4.4.


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


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].


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, 2005 50 % [UMIC, 2005]

Organismos do Governo Regional da Madeira, 2005 45% [UMIC, 2005M]

Câmaras Municipais, 2005 36% [UMIC, 2005C]

Organismos da Administração Pública Central, 2006 53% [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.

5.1. 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.

5.2. 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.


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.

5.3. 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).

Maturidade Organizacional em Gestão de

Projectos

Maturidade Organizacional

em Planeamento

Estratégico de TI

Investimentos em TI

Recursos Humanos de

TI


6. Metodologia de Investigação

A definição da abordagem metodológica é uma componente importante de qualquer trabalho de investigação, porque, sendo assim, delimita detalhadamente o percurso seguido na preparação de todo o processo de investigação.

Para além da importância da metodologia na validação do estudo em causa pretende-se também fornecer informações práticas e detalhadas para investigações futuras, que percorram caminhos similares, de modo a evitar consumo desnecessário de tempo em questões básicas mas essenciais para a qualidade dos resultados da investigação. Acautelar os aspectos metodológicos no processo de investigação constitui uma etapa fundamental para o sucesso do trabalho.

A identificação (e escolha) da metodologia de investigação a usar depende do objecto de estudo, do problema a investigar e das perguntas de investigação. Saliente-se ainda que a escolha da estratégia de investigação influencia os instrumentos a usar [Yin, 1989]. A investigação qualitativa tem sido considerada, por vários autores, como válida para a investigação em SI (tal como o método Estudo de Caso).

Yin (1989, p.23) define o Estudo de Caso como sendo uma estratégia de pesquisa empírica que:

Investiga um fenómeno contemporâneo, dentro do seu contexto de vida real; quando as fronteiras entre o fenómeno e o contexto não são muito claras; onde múltiplas fontes de evidência (informação) são utilizadas.

Este método (e os outros métodos qualitativos) é útil segundo Bonoma (1985, p. 207), ―... quando um fenómeno é amplo e complexo, onde o corpo de conhecimentos existente é insuficiente para permitir a proposição de questões causais e quando um fenómeno não pode ser estudado fora do contexto no qual ele naturalmente ocorre‖, citado por Bressan (2000). Yin (1989) apresenta sinteticamente quatro aplicações para o Método do Estudo de Caso: (1) para explicar ligações causais nas intervenções na vida real, que são muito complexas para serem abordadas pelos surveys ou pelas estratégias experimentais; (2) para descrever o contexto da vida real no qual a intervenção ocorreu; (3) para fazer uma avaliação, ainda que de forma descritiva, da intervenção realizada; (4) para explorar situações onde as intervenções avaliadas não possuem resultados claros e específicos.


Estas definições de Yin (1989) e Bonoma (1985) ajudam a compreender como o objecto de estudo (―Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Pública – Serviços Integrados e Serviços e Fundos Autónomos‖) se enquadra no método de Estudo de Caso.

Yin (1989), também, refere que as questões do tipo ―como‖ requerem metodologias de natureza explanatória, entre as quais os Estudos de Caso. Em relação às questões do tipo ―que‖ ou ―qual‖ o seu objectivo pode ser descrever a incidência ou a prevalência dum determinado fenómeno ou prever determinados resultados e, nesse caso, é apropriado adoptar metodologias quantitativas de investigação. No entanto, o autor afirma que estas questões podem ter, também, um carácter exploratório.

Na realidade, as questões ―qual‖ formuladas nesta tese não pretendem identificar a prevalência (frequência ou incidência) de determinado evento ou resultado, mas antes ajudar a conhecer melhor um fenómeno sobre o qual ainda se sabe pouco – definidas no capítulo 5. Porém, uma análise quantitativa dos dados será necessária.

Com esta convicção e em função dos objectivos específicos deste projecto, do ambiente onde foi desenvolvido, determinou-se que seria adoptada como via para a sua condução, de forma simultânea e articulada, o método de pesquisa qualitativas das Ciências Sociais – o método de Estudo de Caso – no anexo A encontra-se uma síntese do método Estudo de Caso.

Assim, a investigação foi organizada segundo as seguintes etapas metodológicas que se enquadram no método estudo de caso:

1. Rever literatura – efectuou-se um levantamento bibliográfico sobre metodologia de gestão de projectos – PMBOK – e avaliação de projectos de SI/TI, que teve como objectivo 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;

2. Definir o problema de investigação – após a revisão da literatura foi definido a pergunta de investigação, as proposições e o tipo de estudo tal como sugerido por Yin (1989);

3. Escolha das unidades de análise e definição dos instrumentos de recolha de informação - dado a 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 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.

Assim, foi criado um instrumento de recolha de informação – com as variáveis a analisar e critérios para a interpretação dos dados.

4. Estudo de caso – apresenta o estudo realizado para avaliar a maturidade em gestão de projectos na Administração Pública Portuguesa – Serviços Integrados e Serviços e Fundos Autónomos – e aferir da correlação com as seguintes variáveis: maturidade em planeamento estratégico de TI; recursos humanos de TI por recursos humanos globais (%) e a despesa em TI por despesa global (%).

5. Conclusão e Trabalho Futuro – apresentam-se as conclusões do Estudo de Caso e propostas para trabalho futuro.


6.1. Escolha das Unidade de Análise

O presente trabalho de investigação tem subjacente a realização de um estudo transversal à Administração Pública Portuguesas - Serviços Integrados e Serviços e Fundos Autónomos. Dada a impossibilidade de obtenção de dados sobre a totalidade dos serviços foi necessário utilizar uma amostra que, com o mínimo de ambiguidade e imprecisão, representasse as características e a distribuição da população.

É de referir que por razões que se prendem com a oportunidade do trabalho em termos temporais não se incluíram para selecção da amostra as despesas do Sistema da Segurança Social. Assim, esta limita-se exclusivamente às despesas dos Serviços Integrados e dos Serviços e Fundos Autónomos.

Em primeiro lugar, procedeu-se à selecção dos organismos a incluir na amostra através de um levantamento com base nos pagamentos, referentes ao ano de 2007, registados no Sistema Central de Contabilidade (SCC)18.

Depois de encontrado o universo da amostra alvo de estudo, todos os organismos dos Serviços Integrados e Serviços e Fundos Autónomos, delimitou-se a dimensão da amostra utilizando os seguintes critérios:

a) Os organismos com mais gastos de cada ministério calculados a partir da distribuição das despesas pagas pelas rubricas CE 02.2.09 - Comunicações, 07.01.07 - Equipamento de informática, 07.01.09.Y190.A0 - Equipamentos administrativos - hardware de comunicações, 07.01.10.Y200.A0 - Equipamento básico - hardware de comunicações, 07.01.08 - Software informático, 07.02.06 - Material de informática - locação financeira e 02.02.05 - Locação de material informático, no ano de 2007;

b) Pelo menos um organismo de cada ministério e não mais de 4.

A representatividade da amostra seleccionada ascendeu a 51,76% (aproximadamente 257,99 Milhões de Euros) do total de despesas em TI do ano de 2007. Porém, dado o peso do Orçamento da Segurança Social considerou-se oportuno incluir na amostra a entidade mais gastadora de TI desse orçamento.

No anexo B, do presente documento, estão referenciadas as unidades seleccionadas. O nome dos ministérios e organizações nunca será referido por motivos de confidencialidade.

6.2. Instrumento de Recolha de Informação

Neste ponto apresenta-se a escolha e definição dos instrumentos que serão usados na medição das variáveis consideradas para estudo: (1) maturidade em gestão de projectos; (2) maturidade em planeamento estratégico de TI; (3) recursos humanos TI e (4) despesa em TI.

18 Os dados foram extraídos pela DGO, com corte de operações a 9/Set/2008.

19 Y - Corresponde à alínea relativa ao sector institucional, a utilizar nos termos do DL nº 26/2002, de 14 de Fevereiro: A – Administração central – Estado; B – Administração Central – Serviço e Fundos Autónomos.

20 Cfr. o definido na anota de rodapé 19.


Para aferir da maturidade em gestão de projectos de SI/TI e da maturidade em planeamento estratégico TI adopta-se instrumentos de medida já testados e aplicados; para a identificação dos recursos humanos TI e despesa em TI desenvolve-se um instrumento de análise.

6.2.1. Recursos Humanos de TI

A aplicação de ferramentas (e técnicas) de gestão de projecto de SI/TI poderão ser influenciados pelos recursos humanos de TI nas organizações. À partida quanto maior for a percentagem de recursos humanos de TI por recursos humanos globais maior será a maturidade em gestão de projectos de SI/TI.

Assim para responder à proposição: Qual é a correlação entre os recursos humanos de TI por recursos humanos globais (%) e a maturidade em gestão de projectos SI/TI?

Foram definidas variáveis, medidas e critérios de avaliação:

Variáveis e Medidas. Os recursos humanos são caracterizados em dois grandes grupos, pertencentes ou não a área de TI/SI por nível de habilitações literárias – vide com maior detalhe o ponto II do anexo D:

Variáveis Medidas

Número de pessoal em serviço efectivo em 31 de Dezembro de 2005, 2006 e 2007 por nível de escolaridade completa (Sem nível de escolaridade, Básica e Secundária, Superior).

Um valor numérico.

Número de pessoal TI em 31 de Dezembro de 2005, 2006 e 2007 por nível de escolaridade completa (Sem nível de escolaridade, Básica e Secundária, Superior).

Um valor numérico

Tabela 22 – Recursos Humanos de TI – Variáveis e Medidas.

Fonte: Autor.

Critérios para avaliação. Esta característica será estudada correlacionando a maturidade em gestão de projectos com a percentagem da média dos recursos humanos TI, por a média dos recursos humanos globais – entre 2005 e 2007.

6.2.2. Despesa em SI/TI

As organizações que investem mais em SI/TI, ao longo do tempo, devem apresentar superior maturidade em gestão de projectos de SI/TI. Esta característica será estudada correlacionando a maturidade em gestão de projectos de SI/TI com a percentagem da média de despesa em SI/TI sobre a média da despesa global – entre 2005 e 2007.

Assim para responder à proposição: Qual é a correlação entre despesa em SI/TI por despesa global (%) e a maturidade em gestão de projectos SI/TI?

Para definir as variáveis da despesa em SI/TI foi efectuada uma análise do classificador económico das despesas públicas (Decreto-Lei nº 26/2002, de 14 de Fevereiro), com o objectivo de avaliar quais as rubricas passíveis de serem utilizadas para a caracterização das despesas em SI/TI – vide com maior pormenor o anexo C.


Despesa em TI compreende o somatório das despesas classificadas nas rubricas com as seguintes CE: 02.02.09 - Comunicações; 07.01.07 - Equipamento de informática; 07.01.09 - Equipamentos administrativos21; 07.01.10 - Equipamentos básicos22; 07.01.08 - Software informático; 02.02.19 - Manutenção23; 02.02.14 - Estudos, pareceres, projectos e consultoria24; 02.02.20 - Outros trabalhos especializados25; 07.02.06 - Material de informática - locação financeira26; 02.02.05 - Locação de material informático27 e Outras despesas28.

Foram definidas as seguintes variáveis, medidas e critérios de avaliação:

Variáveis e Medidas. As despesas dividem-se em dois grandes grupos: despesas globais e despesas em SI/TI – vide com maior detalhe o ponto III do anexo D:

Variáveis Medidas

Despesa total do organismo. Um valor numérico.

Despesa em TI. Um valor numérico.

Tabela 23 – Despesa em SI/TI – Variáveis e Medidas.

Fonte: Autor.

Critérios para avaliação. Esta característica será estudada correlacionando a maturidade em gestão de projectos com a percentagem da média da despesa em SI/TI (por a média da despesa global) – entre 2005 e 2007.

6.2.3. Maturidade Organizacional em Planeamento Estratégico de TI e Gestão de Projectos de SI/TI

O modelo de maturidade seleccionado, para o estudo de caso, foi o CobiT 4.1. Esta escolha justifica-se pelo facto de o CobiT 4.1 proporcionar um esquema de avaliação disciplinado, organizado, de fácil interpretação e abrangente – ou seja, efectua através de uma só framework a avaliação da maturidade organizacional em gestão de projectos e avaliação da maturidade organizacional em planeamento estratégico de TI.

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

21 Isto é, todas as despesas objecto de classificação económica na rubrica com o código 07.01.09.Y0.A0 – ―Equipamentos administrativos – hardware‖ de comunicações e apenas as despesas em hardware objecto de classificação na rubrica com o código 07.01.09.Y0.B0 –― Equipamentos administrativos – outros‖.

22 Isto é, todas as despesas objecto de classificação económica na rubrica com o código 07.01.10.Y0.A0 – ―Equipamentos básicos – hardware de comunicações‖ e apenas as despesas em hardware objecto de classificação na rubrica com o código 07.01.10.Y0.B0 – ―Equipamentos básicos – outros‖.

23 Apenas as despesas objecto de classificação económica na rubrica com o código 02.02.19 – ―Manutenção‖ referentes às TI.

24 Apenas as despesas objecto de classificação económica na rubrica com o código 02.02.14 – ―Estudos, pareceres, projectos‖ e consultoria referentes às TI.

25 Apenas as despesas objecto de classificação económica na rubrica 02.02.20 – ―Outros trabalhos especializados‖ referentes às TI.

26 Apenas as despesas objecto de classificação económica na rubrica 07.02.06 – ―Material de informática - locação financeira‖ referente a hardware e software.

27 Apenas as despesas objecto de classificação económica na rubrica 02.02.05 – ―Locação de material informático‖ referente a hardware e software.

28 Isto é, outras despesas de TI objecto de classificação económica noutras rubricas.


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 4.4.5.

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 4.4.4.

O instrumento adoptado para aferir a maturidade organizacional em gestão de projectos e maturidade organizacional em planeamento estratégico de TI é a grelha designada por ―Control Objectives Assessment Forms‖. Na parte III do questionário, anexo D, apresenta-se a tradução dos objectivos de controlo associados ao processo ―PO1 – Definir um Plano Estratégico de TI‖ e ―PO10 – Gestão de Projectos‖.

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 4.4.4. A avaliação será efectuada com base no modelo de maturidade genérico do CobiT 4.1.

6.2.3.1. Maturidade Organizacional em Planeamento Estratégico de TI

Assim para responder à proposição: Qual a maturidade em Planeamento Estratégico de TI?

As variáveis, medidas e critérios definidos foram os seguintes:

Variáveis e Medidas. Os seis (6) objectivos de controlo do processo, ―PO1 – Definir um Plano Estratégico de TI‖, propostos pelo CobiT 4.1. Cada objectivo de controlo é definido em 6 níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado). O que se decidiu atribuir, respectivamente, para efeito de cálculo 0,1,2,3,4 e 5 – conforme tabela 24.

Variáveis Medidas

PO1-1.1- Gerir o valor de TI. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO1-1.2- Alinhamento das TI com o Negócio. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO1-1.3- Avaliação de desempenho e capacidade actual.

Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO1-1.4- Plano Estratégico de TI. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO1-1.5 - Planos Tácticos TI. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO1-1.6 – Gerir o Portfolio de TI. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

Tabela 24 – Maturidade em Planeamento Estratégico de TI – Variáveis e Medidas.

Fonte: Autor.

Critérios para avaliação. De acordo com o publicado no estudo de ―IT Governance and Process Maturity‖ o nível de maturidade organizacional será calculado com base na média dos objectivos dos processos. Assim:


Nivel de Maturidade = PO1 − 1.1 + PO1 − 1.2 + PO1 − 1.3 + PO1 − 1.4 + PO1 − 1.5 + PO1 − 1.6

6

6.2.3.2. Maturidade Organizacional em Gestão de Projectos de SI/TI

Para responder à proposição: Qual a maturidade em gestão de projectos de SI/TI?

As variáveis, medidas e critérios definidos foram os seguintes:

Variáveis e Medidas. Os catorze (14) objectivos de controlo do processo, ―PO10 – Gestão de Projectos‖, propostos pelo CobiT 4.1. Cada objectivo de controlo é definido em 6 níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado). O que se decidiu atribuir, respectivamente, para efeito de cálculo 0,1,2,3,4 e 5 – conforme tabela 25.

Variáveis Medidas

PO10-1.1 - Framework de Gestão de Programas.


PO10-1.2 - Framework de Gestão de Projectos. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO10-1.3 - Abordagem de Gestão de Projectos.


PO10-1.4 - Compromisso de Stakeholder. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO10-1.5 - Declaração de Âmbito de Projecto. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO10-1.6 - Fase Inicial do Projecto. Seis níveis de maturidade; de 0 (Inexistente) a 5 (Optimizado).

PO10-1.7 - Planeamento Integrado do Projecto.


PO10-1.8 - Recursos do Projecto. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO10-1.9 - Gestão do Risco do Projecto. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO10-1.10 - Plano de Qualidade do Projecto. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

PO10-1.11 - Controlo das Alterações do Projecto.


PO10-1.12 - Planeamento dos Métodos de Segurança.


PO10-1.13 - Medir, Reportar e Monitorizar o Desempenho do Projecto.


PO10-1.14 - Encerramento do Projecto. Seis níveis de maturidade: de 0 (Inexistente) a 5 (Optimizado).

Tabela 25 – Maturidade em Gestão de Projectos – Variáveis e Medidas.

Fonte: Autor.


Critérios para avaliação. De acordo com o publicado no estudo de ―IT Governance and Process Maturity‖ o nível de maturidade organizacional será calculado com base na média dos objectivos dos processos. Assim:

Nivel de Maturidade = PO10 − 1.1 + ⋯+ PO1 − 1. n

n

Legenda: n=14.

6.2.4. Correlação entre as Variáveis do Estudo

As medidas de correlação indicam a força e a direcção da associação entre os pares de variáveis. A correlação permite obter uma medida através da qual se determina a força ou intensidade de uma associação. A estimativa dessa força é-nos dada pelo cálculo de coeficientes de correlação. Estes coeficientes representam avaliações da proximidade da associação entre duas variáveis. O seu uso alargado nas ciências sociais mostra até que ponto os resultados dos testes de correlação são fáceis de reconhecer e interpretar.

Podem distinguir-se dois tipos de medidas: as medidas de correlação lineares utilizadas com variáveis de intervalo e as medidas de correlação ordinal com variáveis ordinais.

Quando se trabalha com variáveis de intervalo aquela que é, de longe, a medida de correlação mais habitual é o coeficiente de correlação produto-momento de Pearson, muitas vezes designado por r de Pearson.

O r de Pearson permite determinar a força e a direcção das relações lineares entre variáveis. Varia entre -1 e +1. Uma relação de -1 ou de +1 indicaria, respectivamente, uma associação perfeita, negativa ou positiva, entre duas variáveis [Bryman e Cramer, 2003] – vide tabela 26.

Correlação r de Pearson

Co

rrela

ção

Neg

ati

va

Muito forte ≤-0.90 a ≥-1

Forte ≤-0.70 a ≥-0.89

Moderada ≤-0.40 a ≥-0.69

Fraca ≤-0.20 a ≥-0.39

Muito fraca ≤0.0 a ≥0.19

Co

rrela

ção

Po

siti

va

Muito fraca ≥0.0 a ≤0.19

Fraca ≥0.20 a ≤0.39

Moderada ≥0.40 a ≤0.69

Forte ≥0.70 a ≤0.89

Muito forte ≥0.90 a ≤1

Tabela 26 – O que é uma Correlação Elevada? Segundo Cohen e Holliday (1982).

Fonte: Autor.


Utiliza-se o coeficiente de correlação de Pearson para verificar a correlação: entre a maturidade em planeamento estratégico de SI/TI e a maturidade em gestão de projectos de SI/TI; entre os recursos humanos de TI por recursos humanos globais (%) e a maturidade em gestão de projectos SI/T e entre despesa em TI por despesa global (%) e a maturidade em gestão de projectos de SI/TI.

6.3. Estratégia de Recolha de Dados

Yin (1989) refere que as fontes de obtenção de dados que se podem utilizar num estudo de caso são normalmente de seis tipos: (1) documentos; (2) registos de arquivos; (3) entrevistas – de natureza aberta-fechada, focada e tipo survey; (4) observação directa; (5) observação participante e (6) artefactos físicos. Mais ainda, Yin (1989) também recomenda o uso de múltiplas fontes de evidências.

Com o intuito de avaliar a maturidade organizacional em gestão de projectos de SI/TI na Administração Pública seleccionou-se o inquérito por questionário – pois, considerou-se que reúne as condições necessárias para a recolha de dados. Também se utilizou como fonte de dados a documentação fornecida pelas entidades seleccionadas na amostra – os questionários podem ser consultados no Anexo D.

Um aspecto crucial no desenho do inquérito assentou na decisão sobre que tipo de informação se pretendia obter: quantitativa, qualitativa ou ambas. Enquanto a natureza quantitativa possibilita o tratamento estatístico dos dados mais rápido e objectivo; a qualitativa permite aprofundar a compreensão dos resultados quantitativos, captar informação adicional que poderá ter interesse para a pesquisa sobre maturidade organizacional em gestão de projectos SI/TI e a maturidade organizacional em planeamento estratégico em TI.

6.4. Recolha de Dados e Análise de Dados

Uma vez concluído e testado o questionário foi dado início ao trabalho de campo. Contactou-se as entidades seleccionadas na amostra através de carta no sentido de explicar o objectivo do estudo. Foi também solicitada informação relativa ao planeamento estratégico de TI e gestão de projectos (vg. Plano estratégico para as TIs; Planos tácticos; Metodologia de Gestão de Projectos, entre outros) – vide anexo D.

Posteriormente, realizou-se diligências junto das entidades seleccionadas com o objectivo de explicitar os objectivos e metodologia do trabalho - tendo também disponibilizado e prestado esclarecimentos relativamente ao questionário normalizado a ser preenchido pela equipa de cada entidade.

Os questionários foram aplicados junto das entidades seleccionadas para o estudo tendo sido preenchidos pelo responsável da área financeira – a parte I do questionário -, pelo responsável dos recursos humanos – a parte II do questionário – e pelo responsável da área de informática – a parte III.

Durante o período de preenchimento dos questionários verificaram-se contactos regulares com os responsáveis, quer telefonicamente quer presencialmente, de modo a identificar dificuldades, a aclarar dúvidas e a suprimir ambiguidades.

Nos casos em que se encontraram incongruências, dúvidas ou respostas que não reflectiam a realidade, afectou-se uma entrevista com os responsáveis a fim de corrigir tais situações.


A informação relevou-se importante para o estudo na medida em que permitiu aferir o nível de maturidade organizacional em planeamento estratégico de TI e o nível de maturidade organizacional em gestão de projectos de SI/TI.

Uma base de dados em Excel foi criada para permitir a consolidação dos dados das respostas aos questionários recebidos. Posteriormente, foi exportada para SPSS v.16 (significa Statistical Package for the Social Sciences - Conjunto de Programas Estatísticos para as Ciências Sociais) para permitir efectuar um conjunto de estatísticas apresentadas neste documento.


7. Estudo de Caso

Este capítulo apresenta o estudo realizado para avaliar a maturidade organizacional em gestão de projectos na Administração Pública Portuguesa – Serviços Integrados e Serviços e Fundos Autónomos – e aferir da correlação com as variáveis: maturidade organizacional em planeamento estratégico de TI; recursos humanos de TI por recursos humanos globais (%) e a despesa em TI por despesa global (%).

7.1. Características da Amostra

Universo. Dos 40 organismos da Administração Pública – Serviços Integrados (65%) e Serviços e Fundos Autónomos (34%) distribuídos por 15 Ministérios29.

As entidades foram seleccionadas de acordo com os critérios definidos no ponto 6.1 do presente documento.

Respostas aos Inquéritos. O universo analisado é constituído por 37 organismos - Serviços e Fundos Autónomos (32%) e Serviços Integrados (68%) - distribuídos pelos 15 ministérios – vide figura 24.

Três entidades não responderam ao questionário. Das quais duas (2) entidades não responderam ao questionário porque as actividades da função de Tecnologias de Informação são desempenhadas por outras entidades (que responderam ao questionário).

O nome dos Ministérios e Organizações nunca será referido por motivos de confidencialidade.

29 Ou seja, Presidência do Conselho de Ministros; Ministério da Administração Interna; Ministério dos Negócios Estrangeiros; Ministérios das Finanças e da Administração Pública; Ministério da Defesa Nacional; Ministério da Justiça; Ministério do Ambiente, do Ordenamento do Território e do Desenvolvimento Regional; Ministério da Economia e Inovação; Ministério da Agricultura, do Desenvolvimento Rural e das Pescas; Ministério das Obras Públicas, Transportes e Comunicações; Ministério do Trabalho e Solidariedade Nacional; Ministério da Saúde; Ministério da Educação; Ministério da Ciência, Tecnologia e Ensino Superior; Ministério da Cultura.


Figura 24 – Amostra.

Fonte: Autor.

Processo de Envio e Recolha de Dados. Receberam-se as respostas entre 1 de Julho de 2008 e 30 de Dezembro de 2008.

0 1 2 3 4 5

MA

MB

MC

MD

ME

MF

MG

MH

MI

MJ

MK

ML

MM

MN

MO

NÚMERO DE ORGANISMOS

M

I

N

I

S

T

É

R

I

O

S

SI SFA


7.2. Resultados da Análise

Neste ponto apresentam-se os resultados da aplicação do questionário – vide anexo D.

Para melhor compreensão das análises apresentadas relembra-se o significado dos conceitos das seguintes variáveis:

Despesa em TI compreende o somatório das despesas classificadas nas rubricas com as seguintes CE: 02.02.09 – ―Comunicações‖; 07.01.07 – ―Equipamento de informática‖; 07.01.09 – ―Equipamentos administrativos‖30; 07.01.10 - ―Equipamentos básicos‖31; 07.02.06 – ―Material de informática locação financeira‖32; 02.02.05 – ―Locação de material informático‖33; 07.01.08 – ―Software informático‖; 02.02.19 – ―Manutenção‖34; 02.02.14 – ―Estudos, pareceres, projectos e consultoria‖35; 02.02.20 – ―Outros trabalhos especializados‖36 e Outras despesas37.

Nível de Maturidade Organizacional em Gestão de Projectos SI/TI é igual à média dos seguintes objectivos de controlo: ―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 Tácticos TI‖ e ―Gerir o portfolio de TI‖.

Nível de Maturidade Organizacional em Planeamento Estratégico de TI é igual à média dos seguintes objectivos de controlo: ―Framework de gestão de programas‖; ―Framework de gestão de projectos‖; ―Compromisso de stakeholder”; ―Declaração de âmbito de projecto‖; ―Fase inicial do projecto‖; ―Planeamento integrado do projecto‖; ―Recursos do projecto‖; ―Gestão do risco do projecto‖; ―Plano de qualidade do projecto‖; ―Controlo das alterações do projecto‖; ―Planeamento dos métodos de segurança‖; ―Medir, reportar e monitorizar o desempenho do projecto‖ e ―Encerramento do projecto‖.

30 Isto é, todas as despesas objecto de classificação económica na rubrica com o código 07.01.09.Y0.A0 – ―Equipamentos administrativos – hardware de comunicações‖ e apenas as despesas em hardware objecto de classificação na rubrica com o código 07.01.09.Y0.B0 – ―Equipamentos administrativos – outros‖.

31 Isto é, todas as despesas objecto de classificação económica na rubrica com o código 07.01.10.Y0.A0 – ―Equipamentos básicos – hardware de comunicações‖ e apenas as despesas em hardware objecto de classificação na rubrica com o código 07.01.10.Y0.B0 – ―Equipamentos básicos – outros‖.

32 Apenas as despesas objecto de classificação económica na rubrica 07.02.06 – ―Material de informática - locação financeira‖ referente a hardware e software.

33 Apenas as despesas objecto de classificação económica na rubrica 02.02.05 – ―Locação de material informático‖ referente a hardware e software.

34 Apenas as despesas objecto de classificação económica na rubrica com o código 02.02.19 – ―Manutenção‖ referentes às TI.

35 Apenas as despesas objecto de classificação económica na rubrica com o código 02.02.14 – ―Estudos, pareceres, projectos e consultoria‖ referentes às TI.

36 Apenas as despesas objecto de classificação económica na rubrica 02.02.20 – ―Outros trabalhos especializados‖ referentes às TI.

37 Isto é, outras despesas de TI objecto de classificação económica noutras rubricas.


7.2.1. Características da Despesa em TI e Recursos Humanos

Neste ponto apresenta-se a caracterização da despesa em TI e recursos humanos de TI – 2005 a 2007 – dos 37 organismos (que responderam aos questionários). Através dos dados recolhidos examinam-se as tendências segundo várias perspectivas: Serviços Integrados + Serviços e Fundos Autónomos; Serviços Integrados; Serviços e Fundos Autónomos.

7.2.1.1. Qual é a Despesa em TI?

No anexo E apresenta-se de forma pormenorizada a despesa total e a despesa em TI dos 37 organismos da amostra – Serviços Integrados e Serviços de Fundos Autónomos, nos anos 2005 a 2007.

A partir das respostas das entidades verifica-se que em matéria de despesa total em TI, para o triénio 2005 a 2007, foi assumido um encargo global anual médio aproximado de 265.714 milhares de euros – correspondendo aproximadamente: em 2005 a 256.882 milhares de euros; em 2006 a 263.890 milhares de euros; em 2007 a 272.372 milhares de euros (vide, com maior detalhe, a tabela 29).

Para melhor caracterizar o universo analisado procedeu-se à decomposição da despesa efectuada no triénio por sectores (Serviços Integrados e Serviços e Fundos Autónomos), encontrando-se os seus principais resultados apresentados na tabela 27.

Un.: m€ Anos Serviços Integrados

(a) Serviços e Fundos Autónomos

(b) Total de TI

(a+b)

2005 174.044 82.838 256.882

2006 177.868 86.022 263.890

2007 192.346 84.026 272.372

Média 181.419 84.295 265.714

% 68,28% 31,72% 100%

Tabela 27 – Serviços Integrados e Serviços e Fundos Autónomos – Despesa em TI, 2005 a 2007

Fonte: Autor.

Em termos globais nos Serviços Integrados e Serviços e Fundos Autónomos, durante o período considerado, a despesa em TI registou: um acréscimo de aproximadamente 2,73% no ano de 2006 em relação a 2005 e um acréscimo de aproximadamente de 4,73% no ano de 2007 em relação a 2006. Em termos globais, entre 2005 e 2007, houve um crescimento de 7,59% da despesa em TI.

Serviços Integrados.

No referente aos Serviços Integrados, importa enfatizar que, a despesa em TI revelou um acréscimo (+2,20%) em 2006 em relação a 2005 e um acréscimo (+8,14%) em 2007 em relação a 2006, devendo-se fundamentalmente à oscilação da despesa em TI na maior parte das entidades – vide figura 25.


Figura 25 – Serviços Integrados - Evolução da Despesa em TI por Organismo, 2005 a 2007.

Fonte: Autor.

Pela análise da figura 25 é possível verificar a evolução e a distribuição da despesa em TI, nos Serviços Integrados, em todas entidades:

– Entre 2005 e 2006, apresentam um acréscimo da despesa em TI: MBS1 (+42%); MBS3 (+32%); MCS1 (+4%); MDS2 (+18%); MES1 (+292%); MFS3 (+63%); MFS4 (+34%); MGS3 (+211%); MIS2 (+65%); MJS2 (+56%); MMS1 (+89%); MMS2 (+64%) e MOS1 (+11%).

Apresentam um decréscimo da despesa em TI: MBS2 (-17%); MDS3 (-49%); MDS4 (-21%); MES2 (-35%); MES3 (-77%); MFS2 (-33%); MGS1 (-17%); MHS2 (-11%); MIS3 (-2%); MLS2 (-8%); MMS3 (-46%) e MOS2 (-30%);

-200% -100% 0% 100% 200% 300% 400% 500% 600%

MBS1

MBS2

MBS3

MCS1

MDS2

MDS3

MDS4

MES1

MES2

MES3

MFS2

MFS3

MFS4

MGS1

MGS3

MHS2

MIS2

MIS3

MJS2

MLS2

MMS1

MMS2

MMS3

MOS1

MOS2

Variação 2005/2006 Variação 2006/2007


– Entre 2006 e 2007, apresentam um acréscimo da despesa em TI: MBS1 (+27%); MBS3 (+13%); MDS2 (+1%); MDS4 (+28%); MES1 (+198%); MES2 (+8%); MFS2 (+163%); MFS3 (+202%); MGS1 (+8%); MGS3 (+56%); MJS2 (+7%); MLS2 (+5%); MMS1 (+242%); MMS3 (+93%); MOS1 (+38%) e MOS2 (+184%).

Apresentam um decréscimo da despesa em TI: MBS2 (-5%), MCS1 (-28%), MDS3 (-6%), MES3 (-67%), MFS4 (-29%), MHS2 (-6%), MIS2 (-47%); MIS3 (-8%) e MMS2 (-94%).

Conclui-se assim que, para o triénio 2005 a 2007, apenas 36% (9) das entidades (MDS2, MBS1, MBS3, MFS3, MMS1, MOS1, MES1, MJS2 e MGS3) apresentam um crescimento contínuo da despesa em TI; 20% (5) das entidades (MBS2, MDS3, MES3, MHS2 e MIS3) apresentam um decréscimo contínuo da despesa em TI e 44% (11) das entidades (MCS1, MDS4, MES2, MSF2, MFS4, MGS1, MIS2, MLS2, MMS2, MMS3 e MOS2) apresentam uma oscilação da despesa em TI.

Serviços e Fundos Autónomos.

No que concerne aos Serviços e Fundos Autónomos a despesa em TI revelou um acréscimo (+3,84%) no ano de 2006 em relação a 2005 e um decréscimo (-2,32%) no ano de 2007 em relação a 2006, devendo-se fundamentalmente à oscilação da despesa em TI na maior parte das entidades – vide figura 26.

Figura 26 – Serviços e Fundos Autónomos - Evolução da Despesa em TI por Organismo, 2005 a 2007.

Fonte: Autor.

-40% -20% 0% 20% 40% 60% 80% 100%

MAS1

MFS1

MGS2

MGS4

MHS1

MIS1

MJS1

MKS1

MKS2

MLS3

MNS1

MNS2

Variação 2005/2006 Variação 2006/2007


Pela análise da figura 26 é possível verificar a evolução e distribuição da despesa em TI, nos Serviços e Fundos Autónomo, em todas entidades:

– Entre 2005 e 2006, apresentam um acréscimo da despesa em TI: MFS1 (+34%); MHS1 (+11%); MIS1 (+23%); MLS3 (+83%); MNS1 (+44%) e MNS2 (+28%).

Apresentam um decréscimo da despesa em TI: MAS1 (-16%); MGS2 (-3%); MGS4 (-16%); MJS1 (-33%); MKS1 (-7%) e MKS2 (-2%);

– Entre 2006 e 2007, apresentam um acréscimo da despesa em TI: MFS1 (+34%); MHS1 (+11%); MIS1 (+23%); MLS3 (+83%); MNS1 (+44%) e MNS2 (+28%).

Apresentam um decréscimo da despesa em TI: MFS1 (-29%); MGS2 (-25%); MIS1 (-4%); MKS1 (-2%); MLS3 (-9%); MNS1 (-9%) e MNS2 (-16%).

Conclui-se assim que, para o triénio 2005 a 2007, apenas 8,3% (1) das entidades (MHS1) apresentam um crescimento contínuo da despesa em TI; 16,7% (2) das entidades (MGS2 e MKS1) apresentam um decréscimo contínuo da despesa em TI e 75% (9) das entidades (MAS1, MFS1, MGS4, MIS1, MJS1, MKS2, MLS3, MNS1 e MNS2) apresentam uma oscilação da despesa em TI.

Serviços Integrados e Serviços e Fundos Autónomos.

A despesa média anual em TI nos diferentes organismos é bastante diferenciada, conforme se verifica na figura 27:

Figura 27 – Despesa Média Anual em TI por Organismo – 2005 a 2007.

Fonte: Autor.

Da análise à figura 27 infere-se, para o período 2005 a 2007, o seguinte escalonamento da despesa média anual em TI:

– Até 1.000 milhares de euros (m€) - seis (6) entidades - MGS4 (767 m€), MES1 (850 m€), MHS1 (957 m€), MGS3 (818 m€), MJS3 (833 m€) e MOS2 (731 m€);

– Entre 1.001 a 2.000 milhares de euros (m€) - cinco (5) entidades – MDS4 (1.679 m€), MIS2 (1.129 m€), MIS3 (1.945 m€), MNS2 (1.109 m€) e MOS1 (1.459 m€);

0

10.000

20.000

30.000

40.000

50.000

60.000

MA

S1

MB

S1

MB

S2

MB

S3

MC

S1

MD

S2

MD

S3

MD

S4

ME

S1

ME

S2

ME

S3

MF

S1

MF

S2

MF

S3

MF

S4

MG

S1

MG

S2

MG

S3

MG

S4

MH

S1

MH

S2

MIS

1

MIS

2

MIS

3

MJS

1

MJS

2

MK

S1

MK

S2

ML

S2

ML

S3

MM

S1

MM

S2

MM

S3

MN

S1

MN

S2

MO

S1

MO

S2

Despesa Média Anual - 2005/2007


– Entre 2.001 a 3.000 milhares de euros (m€) - duas (2) entidades – MLS3 (2.201 m€) e MHS2 (2.024 m€);

– Entre 3.001 a 4.000 milhares de euros (m€) - quatro (4) entidades – MAS1 (3.978 m€), MJS1 (3.934 m€), MMS1 (3.263 m€) e MMS3 (3.488 m€);

– Entre 4.001 a 5.000 milhares de euros (m€) - cinco (5) entidades - MDS3 (4.629 m€), MES2 (4.195 m€), MES3 (4.399 m€), MGS2 (4.378 m€) e MNS1 (4.472 m€);

– Mais de 5.001 milhares de euros (m€) - quinze (15) entidades – MBS1 (11.683 m€), MBS2 (11.697 m€), MBS3 (11.507 m€), MCS1 (6.622 m€), MDS2 (48.023 m€), MFS1 (10.945 m€), MFS2 (9.687 m€), MFS3 (8.197 m€), MES4 (10.945 m€), MJS1 (14.191 m€), MIS1 (6.373 m€), MKS1 (23.658 m€), MKS2 (21.521 m€), MLS2 (9.550 m€) e MMS2 (7.874 m€).

Na figura 28 apresenta-se a resposta à pergunta “Qual é a despesa em TI por despesa global (%)?”

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 2007.

Fonte: Autor.

O peso da despesa em TI por despesa global (%) é bastante diferenciada nos diversos organismos, como seria de esperar, dado a especificidade da área de intervenção, número de utilizadores, entre outros factores. Apresenta como valor mínimo 0,18%, médio 20,09% e máximo 90,18 – vide com detalhe a tabela 57.

7.2.1.2. Quais são os Recursos Humanos TI?

No anexo E apresenta-se de forma pormenorizada os recursos humanos globais e os recursos humanos em TI dos 37 organismos da amostra – Serviços Integrados e Serviços e Fundos Autónomos, nos anos 2005 a 2007.

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

MA

S1M

BS1

MB

S2M

BS3

MC

S1M

DS2

MD

S3M

DS4

MES

1M

ES2

MES

3M

FS1

MFS

2M

FS3

MFS

4M

GS1

MG

S2M

GS3

MG

S4M

HS1

MH

S2M

IS1

MIS

2M

IS3

MJS

1M

JS2

MK

S1M

KS2

MLS

2M

LS3

MM

S1M

MS2

MM

S3M

NS1

MN

S2M

OS1

MO

S2


A partir das respostas das entidades verifica-se que o rácio entre os recursos humanos de TI por recursos humanos globais, para o triénio 2005 a 2007, é de 2,05% - correspondendo a 1,75% aos Serviços Integrados e 4,33% aos Serviços e Fundos Autónomos – encontrando-se os seus principais resultados apresentados na tabela 28.

Anos Serviços Integrados

(a)

Serviços Fundos Autónomos

(b)

Total

(a+b)

Recu

rso

s

Hu

man

os 2005 81.013 10.984 91.997

2006 79.823 10.539 90.362

2007 78.577 10.539 89.116

Média 239.413 32.062 271.475

Recu

rso

s

Hu

man

os

de T

I

2005 1.384 457 1.841

2006 1.351 461 1.812

2007 1.453 470 1.923

Média 4.188 1.388 5.576

% 1,75% 4,33% 2,05%

Tabela 28 – Serviços Integrados e Serviços Fundos Autónomos – Recursos Humanos TI e Recursos Humanos – 2005 a 2007.

Fonte: Autor.

A percentagem de recursos humanos de TI por recursos humanos globais para o universo das 37 entidades da amostra é pouco significativa – em especial nas entidades pertencentes aos Serviços Integrados.

Saliente-se que, na totalidade dos organismos, as variações entre a percentagem de recursos humanos TI por recursos humanos globais, nos anos 2005/2006 e 2006/2007, são pouco significativas – vide pormenorizadamente a tabela 55.

Na figura 29 apresenta-se a resposta à pergunta “Qual é o rácio entre os recursos humanos de TI e os recursos humanos globais (%) por organismo?”

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 2007.

Fonte: Autor.

0,0%

10,0%

20,0%

30,0%

40,0%

50,0%

60,0%

70,0%

80,0%

90,0%

100,0%

MA

S1

MB

S1

MB

S2

MB

S3

MC

S1

MD

S2

MD

S3

MD

S4

ME

S1

ME

S2

ME

S3

MF

S1

MF

S2

MF

S3

MF

S4

MG

S1

MG

S2

MG

S3

MG

S4

MH

S1

MH

S2

MIS

1

MIS

2

MIS

3

MJS

1

MJS

2

MK

S1

MK

S2

ML

S2

ML

S3

MM

S1

MM

S2

MM

S3

MN

S1

MN

S2

MO

S1

MO

S2


Da análise à figura 29 infere-se para o período 2005 a 2007 o seguinte escalonamento da percentagem de recursos humanos de TI – vide pormenorizadamente a tabela 58:

– Até 1% - cinco (5) entidades - MOS2 (0%); MBS3 (0,2%); MFS3 (0,4%); MBS2 (0,8%) e MFS1 (0,9%);

– Entre 1,01% e 2% - dez (10) entidades - MFS2 (1,1%); MES3 (1,1%); MLS3 (1,3%); MIS2 (1,3%); MKS1 (1,5%); MMS2 (1,5%); MMS1 (1,5%); MMS2 (1,5%); MOS1 (1,7%) e MHS1 (1,9%);

– Entre 2,01% e 3% - cinco (5) entidades – MCS1 (2,4%); MJS2 (2,4%); MGS3 (2,7%); MBS1 (2,8%) e MNS2 (3,0%);

– Entre 3,01% e 4% - uma (1) entidade – MGS4 (3,1%);

– Entre 4,01% e 5% - duas (2) entidades – MIS3 (4,5%) e MDS4 (4,7%);

– Entre 5,01% e 6% - três (3) entidades – MNS1 (5,2%); MGS2 (5,7%) e MIS1 (5,7%);

– Entre 6,01% e 7% - uma (1) entidade – MMS3 (6,5%);

– Entre 7,01 e 8% - uma (1) entidade – MJS1 (7,7%);

– Entre 9,01 e 10% - uma (1) entidade – MGS1 (9,6%);

– Mais de 10,01% - oito (8) entidades – MHS2 (15,4%); MAS1 (16,6%); MES1 (38,9%); MFS4 (53,3%); MDS3 (56,5%); MDS2 (74,1%); MKS2 (77,2%) e MES2 (97,9%).

7.2.1.3. Qual a Correlação Entre a Percentagem de Recursos humanos de TI e a Percentagem de

Despesa em TI?

Analisando a correlação entre a percentagem de recursos humanos de TI e a percentagem de despesa em TI verifica-se que (+0,404) é positiva, moderada e significativa. Ou seja, na nossa amostra, quanto mais elevado é a % percentagem de recursos humanos de TI mais elevado se revela a percentagem da despesa de TI – vide tabela 29.

% RH de TI % Despesa de TI

% RH de TI Pearson Correlation 1,000 ,404*

Sig. (2-tailed) ,013

N 37,000 37

% Despesa de TI Pearson Correlation ,404* 1,000


N 37 37,000

*. Correlation is significant at the 0.05 level (2-tailed).

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.

Fonte: Autor.

7.2.2. Características da Maturidade Organizacional

Neste ponto apresenta-se uma caracterização da maturidade em Planeamento Estratégico de TI e maturidade em Gestão de Projectos de SI/TI dos 37 organismos (que responderam aos questionários). Através dos dados recolhidos examinam-se as tendências segundo várias perspectivas: Serviços Integrados + Serviços e Fundos Autónomos; Serviços Integrados; Serviços e Fundos Autónomos.


7.2.2.1. Qual é Maturidade Organizacional em Planeamento Estratégico de TI?

No anexo E apresenta-se de forma pormenorizada os níveis de maturidade organizacional em planeamento estratégico de TI por organismo.


A figura 30 ilustra o nível de maturidade organizacional em planeamento estratégico de TI:

Figura 30 – Serviços Integrados e Serviços e Fundos Autónomos – Nível de Maturidade Organizacional em Planeamento Estratégico de TI.

Fonte: Autor.

A maturidade organizacional em planeamento estratégico de TI na generalidade dos 37 organismos na Administração Pública – Serviços Integrados e Serviços e Fundos Autónomos – é baixa (isto é, apresentam maturidade inferior ao nível 3 – Definido).

0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5

MAS1

MBS1

MBS2

MBS3

MCS1

MDS2

MDS3

MDS4

MES1

MES2

MES3

MFS1

MFS2

MFS3

MFS4

MGS1

MGS2

MGS3

MGS4

MHS1

MHS2

MIS1

MIS2

MIS3

MJS1

MJS2

MKS1

MKS2

MLS2

MLS3

MMS1

MMS2

MMS3

MNS1

MNS2

MOS1

MOS2

Nível de Maturidade

Org

an

ização


A figura 31 apresenta uma síntese, através do diagrama de extremos-e-quartis38, dos níveis de maturidade dos objectivos de controlo – ―PO1-1.1 - Gerir valor de TI‖, ―PO1-1.2 – Alinhamento das TI com o Negócio‖, ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖, ―PO1-1.4 – Plano Estratégico de TI‖ e ―PO1-1.5 – Planos Tácticos de TI‖ e ―PO1-1.6 – Gerir o Portfolio de TI‖ – e do processo ―PO1 – Planeamento Estratégico de TI‖ (PO1-Media).

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).

Fonte: Autor.

Verifica-se que, para os objectivos de controlo ―PO1-1.1 - Gerir valor de TI‖, ―PO1-1.2 – Alinhamento das TI com o Negócio‖, ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖, ―PO1-1.4 – Plano Estratégico de TI‖ e ―PO1-1.5 – Planos Tácticos de TI‖ o primeiro

38 Diagrama de extremos-e-quartis.

É um tipo de representação gráfica em que se realça algumas características da amostra. O conjunto dos valores da amostra compreendidos entre o 1º e o 3º quartis, que vamos representar por Q1 e Q3, é representado por um rectângulo (caixa) com a mediana indicada por uma barra. A largura do rectângulo não dá qualquer informação. Consideram-se seguidamente duas linhas que unem os meios dos lados do rectângulo com os extremos da amostra. Para obter esta representação começa-se por se recolher da amostra informação sobre 5 números, que são: os 2 extremos (mínimo e máximo); a mediana e o 1º (Q1) e 3º (Q3) quartis. A representação do diagrama de extremos-e-quartis tem o seguinte aspecto:

O extremo inferior é o mínimo da amostra, enquanto que o extremo superior é o máximo da amostra. O rectângulo representa os 50% centrais das observações. [Bryman e Cramer, 2003]


quartil (Q1), por vezes intitulado ―quartil inferior‖, é 1,00, o segundo quartil (Q2), intitulado por mediana, é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00.

Quanto ao objectivo de controlo ―PO1-1.6 – Gerir o Portfolio de TI‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) e terceiro quartil (Q3) é 2,00. O extremo inferior é zero (0) e o extremo superior é 3,00. Porém, a entidade 37 (MKS2) apresenta nível de maturidade igual a 4,00.

Para o processo Planeamento Estratégico em TI (PO1-Media) o primeiro quartil (Q1) é 1,30, o segundo quartil (Q2) é 1,80 e o terceiro quartil (Q3) é 2,70. O extremo inferior é 0,5 e o extremo superior é 4,00.

Analisando a correlação entre o nível de maturidade organizacional dos objectivos de controlo (e o nível de maturidade organizacional) do processo PO1 – Planeamento Estratégico de TI verifica-se que é positiva, forte e significativa – vide tabela 60.


A figura 32 apresenta uma síntese, através do diagrama de extremos-e-quartis39, dos níveis de maturidade dos objectivos de controlo – ―PO1-1.1 - Gerir valor de TI‖, ―PO1-1.2 – Alinhamento das TI com o Negócio‖, ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖, ―PO1-1.4 – Plano Estratégico de TI‖, ―PO1-1.5 – Planos Tácticos de TI‖ e ―PO1-1.6 – Gerir o Portfolio de TI‖ – e do processo ―PO1 – Planeamento Estratégico de TI‖ (PO1-Media).

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).

Fonte: Autor.

39 Verificar as explicações referente ao diagrama de extremos-e-quartis na nota de rodapé 38.


Verifica-se que, para os objectivos de controlo ―PO1-1.1 - Gerir valor de TI‖, ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖, ―PO1-1.4 – Plano Estratégico de TI‖ e ―PO1-1.6 – Gerir o Portfolio de TI‖ o primeiro quartil (Q1), por vezes intitulado ―quartil inferior‖, é 1,00, o segundo quartil (Q2) e o terceiro quartil (Q3) é 2,00. O extremo inferior é zero (0) e o extremo superior é 3,00. Porém, para o objectivo de controlo ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖, entidade 34 (MFS4), e para o objectivo de controlo ―PO1-1.4 – Plano Estratégico de TI‖, entidade 33 (MBS1), as entidades apresentam nível de maturidade igual a 4,00.

Quanto aos objectivos de controlo ―PO1-1.2 – Alinhamento das TI com o Negócio‖ e ―PO1-1.5 – Planos Tácticos de TI‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 3,00.




A figura 33 apresenta uma síntese, através do diagrama de extremos-e-quartis40, dos níveis de maturidade dos objectivos de controlo – ―PO1-1.1 - Gerir valor de TI‖, ―PO1-1.2 – Alinhamento das TI com o Negócio‖, ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖, ―PO1-1.4 – Plano Estratégico de TI‖, ―PO1-1.5 – Planos Tácticos de TI‖ e ―PO1-1.6 – Gerir o Portfolio de TI‖ – e do processo ―PO1 – Planeamento Estratégico de TI‖ (PO1-Media).

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).

Fonte: Autor.



Verifica-se que, para o objectivo de controlo:

– ―PO1-1.1 - Gerir valor de TI‖ o primeiro quartil (Q1), por vezes intitulado ―quartil inferior‖, é 1,50, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO1-1.2 – Alinhamento das TI com o Negócio‖ o primeiro quartil (Q1), por vezes intitulado ―quartil inferior‖, é 1,50, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00;

– ―PO1-1.3 – Avaliação de desempenho e capacidade actual‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00;

– ―PO1-1.4 – Plano Estratégico de TI‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 3,00 e o terceiro quartil (Q3) é 3,50. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO1-1.5 – Planos Tácticos de TI‖ o primeiro quartil (Q1) é 1,50, o segundo quartil (Q2) é 3,00 e terceiro quartil (Q3) é 3,50. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO1-1.6 – Gerir o Portfolio de TI‖ o primeiro quartil (Q1) é 2,00, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00. Porém, a entidade 14 (MAS1) apresenta nível de maturidade igual a 0,00.



7.2.2.2. Qual é a Maturidade Organizacional em Gestão de Projecto de SI/TI?

No anexo E apresenta-se de forma pormenorizada os níveis de maturidade organizacional em gestão de projectos de SI/TI por organismo.


Na figura 34 ilustra-se o nível de maturidade em gestão de projectos de SI/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 2007.

Fonte: Autor.

A maturidade organizacional em gestão de projectos de SI/TI na generalidade dos 37 organismos na Administração Pública – Serviços Integrados e Serviços e Fundos Autónomos – é baixa (isto é, apresentam maturidade inferior ao nível 3 – Definido).

0,0 0,5 1,0 1,5 2,0 2,5 3,0 3,5 4,0 4,5

MAS1

MBS1

MBS2

MBS3

MCS1

MDS2

MDS3

MDS4

MES1

MES2

MES3

MFS1

MFS2

MFS3

MFS4

MGS1

MGS2

MGS3

MGS4

MHS1

MHS2

MIS1

MIS2

MIS3

MJS1

MJS2

MKS1

MKS2

MLS2

MLS3

MMS1

MMS2

MMS3

MNS1

MNS2

MOS1

MOS2


A figura 35 apresenta uma síntese, através do diagrama de extremos-e-quartis41, dos níveis de maturidade dos objectivos de controlo – ―PO10-1.1 – Framework de Gestão de Programa‖, ―PO10-1.2 – Framework de Gestão de Projectos‖, ―PO10-1.3 – Framework de Gestão de Projectos‖, ―PO10-1.3 – Abordagem de Gestão de Projectos‖, ―PO10-1.4 – Compromisso de Stakeholder‖, ―PO10-1.5 – Declaração de Âmbito de Projecto‖, ―PO10-1.6 – Fase Inicial do Projecto‖, ―PO10-1.7 – Planeamento Integrado do Projecto‖, ―PO10-1.8 – Recursos do Projecto‖, ―PO10-1.9 – Gestão do Risco do Projecto‖, ―PO10.1.10 – Planeamento de Qualidade do Projecto‖, ―PO10-1.10 – Plano de Qualidade do Projecto‖ , ―PO10-1.11 – Controlo das Alterações do Projecto‖, ―PO10-1.12 – Planeamento de Métodos de Segurança‖, ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ e ―PO10-1.14 – Encerramento do Projecto‖ - e do processo ―Gestão de Projectos de SI/TI ‖ (PO10-Media).

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).

Fonte: Autor.


– ―PO10-1.1 – Framework de Gestão de Programa‖, ―PO10-1.2 – Framework de Gestão de Projectos‖ e ―PO10-1.1.0 – Plano de Qualidade do Projecto‖ o primeiro quartil (Q1) e segundo quartil (Q2) é 1,00 e o terceiro quartil (Q3) é 2,00. O extremo inferior é zero e o extremo superior é 3,00.

Porém, para o objectivo de controlo ―PO10-1.1 – Framework de Gestão de Programa‖ a entidade 17 (MJS1) e a entidade 27 (MLS2) apresentam nível de maturidade igual a 4,00. Para o objectivo de controlo ―PO10-1.2 – Framework de Gestão de Projectos‖ e ―PO10-1.1.0 – Plano de Qualidade do Projecto‖ a entidade 17 (MJS1) apresenta nível de maturidade igual a 4,00;

– ―PO10-1.3 – Abordagem de Gestão de Projectos‖ o primeiro quartil (Q1) e segundo quartil (Q2) é 1,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero e o extremo superior é 4,00;



– ―PO10-1.4 – Compromisso de Stakeholder‖, ―PO10-1.5 – Declaração de Âmbito de projecto‖, ―PO10-1.6 – Fase Inicial do Projecto‖, ―PO10-1.7 – Planeamento Integrado do Projecto‖ e ―PO10-1.11 – Controlo das alterações do projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero e o extremo superior é 4,00;

– ―PO10-1.8 – Recursos do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,0 e o extremo superior é 4,00;

– ―PO10-1.9 – Gestão do Risco do Projecto‖ e ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) e o terceiro quartil (Q3) é 2,00. O extremo inferior é 1,0 e o extremo superior é 3,00.

Porém, para o objectivo de controlo ―PO10-1.9 – Gestão do Risco do Projecto‖ a entidade 3 (MGS4) e a entidade 17 (MJS1) apresentam nível de maturidade igual a 4,00. Para o objectivo de controlo ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ a entidade 17 (MJS1) apresenta nível de maturidade igual a 4,00.

– ―PO10-1.12 – Planeamento de Métodos de Segurança‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 5,00;

– ―PO10-1.14 – Encerramento do Projecto‖o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

Para o processo Gestão de Projectos de SI/TI (PO10-Media) o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 1,60 e o terceiro quartil (Q3) é 2,20. O extremo inferior é 0,5 e o extremo superior é 4,00.

Analisando a correlação entre o nível de maturidade organizacional dos objectivos de controlo (e o nível de maturidade organizacional) do processo PO10 – Gestão de projectos verifica-se que é positiva, forte e significativa – vide tabela 60.


A figura 36 apresenta uma síntese, através do diagrama de extremos-e-quartis42, dos níveis de maturidade dos objectivos de controlo – ―PO10-1.1 – Framework de Gestão de Programa‖, ―PO10-1.2 – Framework de Gestão de Projectos‖, ―PO10-1.3 – Framework de Gestão de Projectos‖, ―PO10-1.3 – Abordagem de Gestão de Projectos‖, ―PO10-1.4 – Compromisso de Stakeholder‖, ―PO10-1.5 – Declaração de Âmbito de Projecto‖, ―PO10-1.6 – Fase Inicial do Projecto‖, ―PO10-1.7 – Planeamento Integrado do Projecto‖, ―PO10-1.8 – Recursos do Projecto‖, ―PO10-1.9 – Gestão do Risco do Projecto‖, ―PO10.1.10 – Planeamento de Qualidade do Projecto‖, ―PO10-1.10 – Plano de Qualidade do Projecto‖, ―PO10-1.11 – Controlo das Alterações do Projecto‖, ―PO10-1.12 – Planeamento de Métodos de Segurança‖, ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ e ―PO10-1.14 – Encerramento do Projecto‖ - e do processo ―Gestão de Projectos de SI/TI ‖ (PO10-Media).




Processo PO10 (Gestão de Projectos).

Fonte: Autor.


– ―PO10-1.1 – Framework de Gestão de Programa‖, ―PO10-1.2 – Framework de Gestão de Projectos‖, ―PO10-1.4 – Compromisso de Stakeholder‖, ―PO10-1.9 – Gestão do Risco do Projecto‖, ―PO10-1.1.0 – Plano de Qualidade do Projecto‖, ―PO10-1.11 – Controlo das Alterações do Projecto‖, ―PO10-1.12 – Planeamento de Métodos de Segurança‖, ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ e ―PO10-1.14 – Encerramento do Projecto‖ o primeiro quartil (Q1) e segundo quartil (Q2) é 1,00 e o terceiro quartil (Q3) é 2,00. O extremo inferior é zero (0) e o extremo superior é 3,00;

Porém, para o objectivo de controlo ―PO10-1.1 – Framework de Gestão de Programa‖ a entidade 27 (MLS2) e a entidade 32 (MES3) apresentam nível de maturidade igual a 4,00. Para o objectivo de controlo ―PO10-1.4 – Compromisso de Stakeholder‖ a entidade 16 (MMS3) e a entidade 27 (MLS2) apresentam nível de maturidade igual a 4,00;

– ―PO10-1.3 – Abordagem de Gestão de Projectos‖ o primeiro quartil (Q1) e segundo quartil (Q2) é 1,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.5 – Declaração de Âmbito de projecto‖ o primeiro quartil (Q1) é 1,00, segundo quartil (Q2) e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 3,00;

– ―PO10-1.6 – Fase Inicial do Projecto‖ e ―PO10-1.8 – Recursos do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.7 – Planeamento Integrado do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00.





A figura 37 apresenta uma síntese, através do diagrama de extremos-e-quartis43, dos níveis de maturidade dos objectivos de controlo – ―PO10-1.1 – Framework de Gestão de Programa‖, ―PO10-1.2 – Framework de Gestão de Projectos‖, ―PO10-1.3 – Framework de Gestão de Projectos‖, ―PO10-1.3 – Abordagem de Gestão de Projectos‖, ―PO10-1.4 – Compromisso de Stakeholder‖, ―PO10-1.5 – Declaração de Âmbito de Projecto‖, ―PO10-1.6 – Fase Inicial do Projecto‖, ―PO10-1.7 – Planeamento Integrado do Projecto‖, ―PO10-1.8 – Recursos do Projecto‖, ―PO10-1.9 – Gestão do Risco do Projecto‖, ―PO10.1.10 – Planeamento de Qualidade do Projecto‖, ―PO10-1.10 – Plano de Qualidade do Projecto‖, ―PO10-1.11 – Controlo das Alterações do Projecto‖, ―PO10-1.12 – Planeamento de Métodos de Segurança‖, ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ e ―PO10-1.14 – Encerramento do Projecto‖ - e do processo ―Gestão de Projectos de SI/TI ‖ (PO10-Media):


Processo PO10 (Gestão de Projectos).

Fonte: Autor.




– ―PO10-1.1 – Framework de Gestão de Programa‖ o primeiro quartil (Q1) e segundo quartil (Q2) é 1,00 e o terceiro quartil (Q3) é 2,50. O extremo inferior é 1,00 e o extremo superior é 4,00;

– ―PO10-1.2 – Framework de Gestão de Projectos‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 1,50 e o terceiro quartil (Q3) é 2,50. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.3 – Abordagem de Gestão de Projectos‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00;

– ―PO10-1.4 – Compromisso de Stakeholder” o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.5 – Declaração de Âmbito de projecto‖ e ―PO10-1.6 – Fase Inicial do Projecto‖ o primeiro quartil (Q1) é 2,00, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00. Porém, a entidade 14 (MAS1) apresenta nível de maturidade igual a 0,00;

– ―PO10-1.7 – Planeamento Integrado do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.8 – Recursos do Projecto‖ e ―PO10-1.9 – Gestão do Risco do Projecto‖ o primeiro quartil (Q1) e o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00;

– ―PO10-1.1.0 – Plano de Qualidade do Projecto‖ o primeiro quartil (Q1) é 0,50, o segundo quartil (Q2) é 1,00 e o terceiro quartil (Q3) é 2,50. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.11 – Controlo das Alterações do Projecto‖ o primeiro quartil (Q1) é 1,50, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.12 – Planeamento de Métodos de Segurança‖ o primeiro quartil (Q1) é 1,50, o segundo quartil (Q2) é 2,50 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,0 e o extremo superior é 5,00;

– ―PO10-1.13 – Medir, Reportar e Monitorizar o Desempenho do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 2,50. O extremo inferior é zero (0) e o extremo superior é 4,00;

– ―PO10-1.14 – Encerramento do Projecto‖ o primeiro quartil (Q1) é 1,00, o segundo quartil (Q2) é 2,00 e o terceiro quartil (Q3) é 3,00. O extremo inferior é 1,00 e o extremo superior é 4,00.




7.2.3. Análise das Proposições

Neste ponto apresenta-se a análise às proposições deste estudo. Efectua-se uma análise das proposições em cinco (5) vertentes: Serviços Integrados e Serviços e Fundos Autónomos; Serviços Integrados; Serviços e Fundos Autónomos; Organismos prestadores de serviços de SI/TI; Serviços Integrados e Serviços e Fundos Autónomos, com excepção dos organismos prestadores de serviços de SI/TI.

7.2.3.1. Qual é a correlação entre a Maturidade em Gestão de Projecto de SI/TI e a Maturidade em

Planeamento Estratégico TI?

Serviços Integrados e Serviços e Fundos Autónomos. A correlação entre a maturidade organizacional em planeamento estratégico de SI/TI e a maturidade organizacional em gestão de projectos (+0,556) é positiva, moderada e significativa. Ou seja, na nossa amostra, quanto mais elevado é o nível de maturidade organizacional em planeamento estratégico de SI/TI mais elevado se revela o nível de maturidade organizacional em gestão de projectos – conforme tabela 30.

PO1-Media PO10-Media

PO1-Media Pearson Correlation 1 ,556(**) Sig. (2-tailed) ,000 N 37 37 PO10-Media Pearson Correlation ,556(**) 1 Sig. (2-tailed) ,000 N 37 37

** Correlation is significant at the 0.01 level (2-tailed).

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

Fonte: Autor.

Serviços e Fundos Autónomos. A correlação entre o nível de maturidade organizacional em planeamento estratégico de SI/TI e o nível de maturidade organizacional em gestão de projectos (+0,583) é positiva, moderada e significativa. Ou seja, na nossa amostra, quanto mais elevado é o nível de maturidade organizacional em planeamento estratégico de SI/TI mais elevado se revela o nível de maturidade organizacional em gestão de projectos – conforme tabela 31.


PO1-Media Pearson Correlation 1 ,583(*)


N 12 12

PO10-Media Pearson Correlation ,583(*) 1


N 12 12

* Correlation is significant at the 0.05 level (2-tailed).

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.

Fonte: Autor.


Serviços Integrados. A correlação entre o nível de maturidade organizacional em planeamento estratégico de SI/TI e o nível de maturidade organizacional em gestão de projectos (+0,458) é positiva, moderada e significativa. Ou seja, na nossa amostra, quanto mais elevado é o nível de maturidade organizacional em planeamento estratégico de SI/TI mais elevado se revela o nível de maturidade organizacional em gestão de projectos – conforme tabela 32.


PO1-Media Pearson Correlation 1 ,458(*)


N 25 25

PO10-Media Pearson Correlation ,458(*) 1


N 25 25 * Correlation is significant at the 0.05 level (2-tailed).

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.

Fonte: Autor.

Organismos Prestadores de Serviços SI/TI. A correlação entre o nível de maturidade organizacional em planeamento estratégico de SI/TI e o nível de maturidade organizacional em gestão de projectos (-0,461) é negativa, moderada e não significativa. Ou seja, na nossa amostra, quanto mais elevado é o nível de maturidade organizacional em planeamento estratégico de SI/TI mais baixo é o nível de maturidade organizacional em gestão de projectos – conforme tabela 33.


PO1-Media Pearson Correlation 1 -,461


N 4 4

PO10-Media Pearson Correlation -,461 1


N 4 4

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

Fonte: Autor.

Verifica-se que a correlação da dimensão Organismos Prestadores de Serviços SI/TI é influenciada pela entidade MKS2. Após se remover da análise essa entidade verifica-se que a correlação entre o nível de maturidade organizacional em planeamento estratégico de SI/TI e o nível de maturidade organizacional em gestão de projectos (+0,924) é positiva, muito forte e não significativa – conforme tabela 34.



PO1-Media Pearson Correlation 1 ,924


N 3 3

PO10-Media Pearson Correlation ,924 1


N 3 3

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).

Fonte: Autor.

Serviços Integrados e Serviços de Fundos Autónomos, com excepção dos organismos prestadores de serviços SI/TI. A correlação entre o nível de maturidade organizacional em planeamento estratégico de SI/TI e o nível de maturidade organizacional em gestão de projectos (+0,639) é positiva, moderada e significativa. Ou seja, na nossa amostra, quanto mais elevado é o nível de maturidade organizacional em planeamento estratégico de SI/TI mais elevado se revela o nível de maturidade organizacional em gestão de projectos de SI/TI – conforme tabela 35.


PO1-Media Pearson Correlation 1 ,639(**)


N 33 33

PO10-Media Pearson Correlation ,639(**) 1


N 33 33

**Correlation is significant at the 0.01 level (2-tailed).

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.

Fonte: Autor.

7.2.3.2. Correlações entre a Maturidade em Gestão de Projectos SI/TI e Recursos Humanos de TI por

Recursos Humanos Globais (%)

Serviços Integrados e Serviços e Fundos Autónomos. A correlação entre a maturidade organizacional em gestão de projectos e a percentagem de recursos humanos de TI por recursos humanos globais (+0,108) é positiva, muito fraca e não significativa – conforme tabela 36.

PO10-Media %



N 37 37

% Pearson Correlation ,108 1


N 37 37

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 (%).

Fonte: Autor.


Serviços e Fundos Autónomos. A correlação entre a maturidade organizacional em gestão de projectos e a percentagem de recursos humanos de TI por recursos humanos globais (+0,386) é positiva, fraca e não significativa – conforme tabela 37.

PO10-Media %



N 12 12



N 12 12

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 (%)

Fonte: Autor.

Serviços Integrados. A correlação entre a maturidade organizacional em gestão de projectos SI/TI e a percentagem de recursos humanos de TI por recursos humanos globais (+0,036) é positiva, muito fraca e não significativa – conforme tabela 38.

PO10-Media %



N 25 25



N 25 25

Tabela 38 – Serviços Integrados - Correlação entre Maturidade em Gestão de Projectos SI/TI e Recursos Humanos TI por Recursos Humanos Globais (%).

Fonte: Autor.

Organismos Prestadores de Serviços SI/TI. A correlação entre a maturidade organizacional em gestão de projectos e a percentagem de recursos humanos de TI (+0,561) é positiva, moderada e não significativa – conforme tabela 39.

PO10-Media %



N 4 4



N 4 4

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.

Fonte: Autor.

Serviços Integrados e Serviços de Fundos Autónomos, com excepção dos Organismos

Prestadores de Serviços SI/TI. A correlação entre a maturidade organizacional em gestão de projectos e a percentagem de recursos humanos de TI (-0,213) é negativa, fraca e não significativa – conforme tabela 40.


PO10-Media %

PO10-Media Pearson Correlation 1 -,213


N 33 33

% Pearson Correlation -,213 1


N 33 33

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.

Fonte: Autor.

7.2.3.3. Correlações entre a Maturidade Organizacional em Gestão de Projecto de SI/TI e a Despesa em

TI por Despesa Global (%)

Serviços Integrados e Serviços e Fundos Autónomos. A correlação entre a maturidade organizacional em gestão de projectos e a despesa em TI por despesa global (+0,206) é positiva, fraca e não significativa – conforme tabela 41.

PO10-Media M_DESP_TI/M_DESP

PO10-Media Pearson Correlation 1 ,206 Sig. (2-tailed) ,221 N 37 37 M_DESP_TI/M_DESP Pearson Correlation ,206 1 Sig. (2-tailed) ,221 N 37 37

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 (%).

Fonte: Autor.

Serviços e Fundos Autónomos. A correlação entre a maturidade organizacional em gestão de projectos e a despesa em TI por despesa global (+0,228) é positiva, fraca e não significativa – conforme tabela 42.



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 (%).

Fonte: Autor.

Serviços Integrados. A correlação entre a maturidade organizacional em gestão de projectos e a despesa em TI por despesa global (+0,266) é positiva, fraca e não significativa – conforme tabela 43.





N 25 25

M_DESP_TIC/M_DESP Pearson Correlation ,266 1


N 25 25

Tabela 43 – Serviços Integrados - Correlação entre Maturidade Organizacional em Gestão de Projectos SI/TI e Despesa em TI por Despesa Global (%).

Fonte: Autor.

Organismos Prestadores de Serviços SI/TI. A correlação entre a maturidade organizacional em gestão de projectos e a despesa em TI por despesa global (+0,462) é positiva, moderada e não significativa – conforme tabela 44.

PO10-Media M_DESP_TIC/M_DESP


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 (%).

Fonte: Autor.

Serviços Integrados e Serviços e Fundos Autónomos, com excepção dos organismos de SI/TI prestadores de serviços. A correlação entre a maturidade organizacional em gestão de projectos e a despesa em TI por despesa global (+0,013) é positiva, muito fraca e não significativa – conforme tabela 45.


PO10-Media Pearson Correlation 1 ,013 Sig. (2-tailed) ,942 N 33 33 M_DESP_TI/M_DESP Pearson Correlation -,013 1 Sig. (2-tailed) ,942 N 33 33

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 (%).

Fonte: Autor.

7.3. Síntese dos Resultados do Estudo de Caso

Tendo em atenção os resultados do estudo de caso conclui-se o seguinte:

Despesa em TI – 2005 a 2007

a) A despesa total em TI para os Serviços Integrados e Serviços e Fundos Autónomos representa um encargo global anual médio aproximado de 265.714 milhares de euros (256.882 milhares euros em 2005; 263.890 milhares de euros em 2006; 272.372 milhares de euros em 2007).

Os Serviços Integrados representam em média nos três anos analisados cerca de 68,28% da


despesa em TI. Os restantes 31,72% dizem respeito aos Serviços e Fundos Autónomos;

Recursos humanos de TI – 2005 a 2007

b) O rácio entre os recursos humanos de TI por recursos humanos globais, no periodo analisado, é de 2,05% (1,75%, Serviços Integrados; 4,33%, Serviços e Fundos Autónomos) – isto é, a percentagem de recursos humanos de TI é pouco significativa – em especial nas entidades pertencentes aos Serviços Integrados.

As variações entre a percentagem de recursos humanos TI, nos anos 2005/2006 e 2006/2007, são pouco significativas;

Maturidade em Planeamento Estratégico de TI, 2008

c) Para o Planeamento Estratégico de TI consta-se que o nível de maturidade na generalidade das entidades é muito baixo. Senão vejamos:

Serviços Integrados e Serviços e Fundos Autónomos (37 entidades): a mediana da maturidade é 1,8; 50% das entidades apresentam nível de maturidade entre 1,3 e 2,70; o valor mínimo é 0,5 e o valor máximo é 4,0;

Serviços Integrados (25 entidades): a mediana da maturidade é 1,7; 50% das entidades apresentam nível de maturidade entre 1,0 e 2,30; o valor mínimo é 0,7 e o valor máximo é 2,8;

Serviços e Fundos Autónomos (12 entidades): a mediana da maturidade é 2,40; 50% das entidades apresentam nível de maturidade entre 1,85 e 3,0; o valor mínimo é 0,5 e o valor máximo é 4,0;

Maturidade em Gestão de Projectos de SI/TI, 2008

d) Para a Gestão de Projectos de TI consta-se que o nível de maturidade na generalidade das entidades é muito baixo. Senão vejamos:



Serviços e Fundos Autónomos (12 entidades): a mediana da maturidade é 1,95; 50% das entidades apresentam nível de maturidade entre 1,55 e 2,8; o valor mínimo é 0,6 e o valor máximo é 4,0;

Correlação entre a maturidade em planeamento estratégico de SI/TI e a maturidade em gestão de projectos de SI/TI

e) Os resultados obtidos permitem constatar que as organizações com maior maturidade em planeamento estratégico de TI possuem maior maturidade em gestão de projectos de SI/TI, tal como é sugerido pelo PMI [PMKBOK, 2004], ou seja as duas variáveis apresentam correlações positivas, moderadas e significativas. Com excepão da análise efectuada na vertente de organismos prestadores de serviços de SI/TI. Dado a dimensão da amostra ser pequena apenas


uma entidade influencia os resultados – vide tabela 46;

Serviços Integrados e Serviços e Fundos Autónomos

Pearson Correlation ,556(**)


N 37

Serviços e Fundos Autónomos Pearson Correlation ,583(*)


N 12

Serviços Integrados Pearson Correlation ,458(*)


N 25 Organismos Prestadores de Serviços de SI/TI

Pearson Correlation -,461


N 4

Organismos Prestadores de Serviços de SI/TI, removendo a entidade MKS2

Pearson Correlation ,924


N 3

Serviços Integrados e Serviços e Fundos Autónomos, com a excepção dos organismos prestadores de serviços SI/TI

Pearson Correlation ,639(**)


N 33

* Correlation is significant at the 0.05 level (2-tailed). ** Correlation is significant at the 0.01 level (2-tailed).

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.

Fonte: Autor.

Correlação entre os recursos humanos de TI por recursos humanos globais (%) e a maturidade em gestão de projectos SI/TI

f) Os resultados obtidos permitem constatar que as organizações que possuem maior percentagem de recursos humanos de TI não possuem maturidade de gestão de projectos superior – vide tabela 47;




N 37

Serviços e Fundos Autónomos Pearson Correlation ,386


N 12

Serviços Integrados Pearson Correlation ,036


N 25

Organismos Prestadores de Serviços de SI/TI



N 4

Serviços Integrados e Serviços e Fundos Autónomos, com a excepção dos organismos prestadores de serviços SI/TI

Pearson Correlation -,213


N 33

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.

Fonte: Autor.


Correlação entre despesa em TI por despesa global (%) e a maturidade em gestão de projectos de SI/TI

g) Os resultados obtidos permitem constatar que as organizações que investem mais em SI/TI, ao longo do tempo, não apresentem maior maturidade em gestão de projectos de SI/TI – vide tabela 48.




N 37

Serviços e Fundos Autónomos



N 12

Serviços Integrados Pearson Correlation ,266


N 25

Organismos Prestadores de Serviços de SI/TI



N 4

Serviços Integrados e Serviços e Fundos Autónomos, com excepção dos prestadores de serviços



N 33

Tabela 48 – Correlação entre a Percentagem a Despesa em TI e Nível de Maturidade Organizacional em Gestão de Projectos SI/TI.

Fonte: Autor.


8. Conclusões e Trabalho Futuro

Este capítulo sintetiza os pressupostos teóricos assumidos, as conclusões principais e o contributo teórico da tese. Por fim, apresenta as limitações da investigação e sugerem-se pistas para futuras investigações.

8.1. Conclusões

A presente investigação é orientada para avaliar a maturidade organizacional em gestão de projectos de SI/TI na Administração Pública Portuguesa, com particular ênfase para o problema definido no ponto 5. A investigação seguiu a metodologia definida no ponto 6, tendo os resultados do Estudo de Caso relatados no ponto 7, e permitiu concluir o seguinte:

8.1.1. Relativamente à despesa Total e despesa em TI – 2005 a 2007 (vide ponto 7.2.1.1):

a) Em matéria de despesa total, para o triénio em análise, as 37 entidades assumiram um encargo global anual médio aproximado de 265.714 milhares de euros (256.882 milhares euros em 2005; 263.890 milhares de euros em 2006; 272.372 milhares de euros em 2007).

Os Serviços Integrados representam em média nos três anos analisados cerca de 68,28% da despesa em TI. Os restantes 31,72% dizem respeito aos Serviços e Fundos Autónomos;

b) Verifica-se uma tendência de acréscimo da despesa em TI, no período analisado, com diferenças em cada ano:

No biénio 2005/2006, a despesa em TI registou um crescimento anual médio de 2,73%, motivada pelo acréscimo da despesa em TI nos Serviços Integrados (+2,20%) e nos Serviços e Fundos Autónomos (+3,84%);

No biénio 2006/2007, a despesa em TI registou um crescimento anual médio de 4,73%, motivada pelo aumento da despesa em TI nos Serviços Integrados (+8,14%). Tendo-se verificado um decréscimo da despesa em TI nos Serviços e Fundos Autónomos (-2,32%);

c) Cerca de 41% das entidades analisadas despenderam em média, no triénio 2005/2007, mais de 5.001 milhares de euros anualmente. As restantes 59% das entidades analisadas despenderam valores inferiores – vide tabela 49;


Despesa média Anual Nº de Entidades

Até 1.000 milhares de euros 6

Entre 1.001 a 2.000 milhares de euros 5




Mais de 5.001 milhares de euros 15

Tabela 49 – Escalonamento da Despesa Média Anual vs Número de Entidades

Fonte: Autor.

d) O peso despesa em TI por despesa global (%) é bastante diferenciada nos diversos organismos,

como seria de esperar, dado a especificidade da área de intervenção, número de utilizadores, entre outros factores. Apresenta como valor mínimo 0,18%, médio 20,09% e máximo 90,18 – vide com detalhe a tabela 57.

8.1.2. Relativamente aos Recursos Humanos Globais e Recursos Humanos de TI – 2005 a 2007 (vide

ponto 7.2.1.2):

e) O rácio entre os recursos humanos de TI por recursos humanos globais, no período analisado, é de 2,05% (1,75%, Serviços Integrados; 4,33%, Serviços e Fundos Autónomos). Isto é, a percentagem de recursos humanos de TI é pouco significativa – em especial nas entidades pertencentes aos Serviços Integrados.

As variações entre a percentagem de recursos humanos TI, nos anos 2005/2006 e 2006/2007, são pouco significativas – vide tabela 55;

f) Cerca de 22% das entidades analisadas dispõem de mais de 10,01% de recursos humanos de TI. As restantes 78% das entidades analisadas dispõem de um valor inferior – vide tabela 50.

% Recursos Humanos de TI Nº de Entidades

Até 1% 5

Entre 1,01% a 2,00% 10

Entre 2,01% a 3,00% 5

Entre 3,01% a 4,00% 1

Entre 4.01% a 5,00% 2

Entre 5.01% a 6,00% 3

Entre 6.01% a 7,00% 1

Entre 7.01% a 8,00% 1

Entre 9.01% a 10,00% 1

Mais de 10,01% 8

Tabela 50 – Escalonamento da % de Recursos Humanos de TI vs Número de Entidades

Fonte: Autor.


8.1.3. No que respeita à Maturidade Organizacional em Planeamento Estratégico de TI – 2008 (vide

ponto 7.2.2.1):

g) O estudo demonstrou que o nível de maturidade em planeamento estratégico de TI, na generalidade, das entidades é muito baixo. Assim, vejamos para:

Os Serviços Integrados e Serviços e Fundos Autónomos (37 entidades): a mediana da maturidade é 1,8; 50% das entidades apresentam nível de maturidade entre 1,3 e 2,70; o valor mínimo é 0,5 e o valor máximo é 4,0;

Os Serviços Integrados (25 entidades): a mediana da maturidade é 1,7; 50% das entidades apresentam nível de maturidade entre 1,0 e 2,30; o valor mínimo é 0,7 e o valor máximo é 2,8;

Os Serviços e Fundos Autónomos (12 entidades): a mediana da maturidade é 2,40; 50% das entidades apresentam nível de maturidade entre 1,85 e 3,0; o valor mínimo é 0,5 e o valor máximo é 4,0.

Ressalte-se ainda que, os Serviços e Fundos Autónomos apresentam nível de maturidade em planeamento estratégico superior aos Serviços Integrados.

8.1.4. No que respeita à Maturidade Organizacional em Gestão de Projectos de SI/TI – 2008 (vide ponto

7.2.2.2):

h) O estudo demonstrou que o nível de maturidade em gestão de projectos de SI/TI, na generalidade, das entidades é muito baixo. Ou seja, para os:



Serviços e Fundos Autónomos (12 entidades): a mediana da maturidade é 1,95; 50% das entidades apresentam nível de maturidade entre 1,55 e 2,8; o valor mínimo é 0,6 e o valor máximo é 4,0.

Ressalte-se ainda que, os Serviços e Fundos Autónomos apresentam nível de maturidade em gestão de projectos de SI/TI superior aos Serviços Integrados.

8.1.5. Quanto à Correlação entre a Maturidade em Planeamento Estratégico de TI e a Maturidade em

Gestão de Projectos de SI/TI (vide ponto 7.2.3):

h) A análise à correlação entre a maturidade em planeamento estratégico de TI e a maturidade em gestão de projectos de SI/TI levou à confirmação da seguinte proposição:

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 [PMKBOK, 2004].


8.1.6. Quanto à Correlação entre os Recursos Humanos de TI por Recursos Humanos Globais (%) e a

Maturidade em Gestão de Projectos SI/TI (vide ponto 7.2.3):

i) A análise à correlação entre os recursos humanos de TI por recursos humanos globais (%) e a maturidade em gestão de projectos SI/TI levou à rejeição da seguinte proposição:

As organizações que possuem maior percentagem de recursos humanos de TI possuem também uma maturidade de gestão de projectos superior.

8.1.7. Quanto à correlação entre Despesa em TI por Despesa global (%) e a Maturidade em Gestão de

Projectos de SI/TI (vide ponto 7.2.3):

j) A análise à correlação entre despesa em TI por despesa global (%) e a maturidade em gestão de projectos de SI/TI levou à rejeição da seguinte proposição:

As organizações que investem mais em SI/TI, ao longo do tempo, apresentem maior maturidade em gestão de projectos de SI/TI.

8.2. Limitações e Constrangimentos ao Trabalho

Cabe reconhecer algumas limitações e constrangimentos deste trabalho em função da metodologia adoptada:

1. O uso de amostra não aleatória impossibilita, do ponto de vista estatístico, a generalização das conclusões para a totalidade dos organismos da Administração Pública;

2. Um trabalho desta natureza requer um longo periodo de tempo. Deste modo, para a realização do estudo de caso foi necessário mais de 1 ano de trabalho. Daqui, resultando o não permitir efectuar um maior aprofundamento e alargamento de âmbito.

8.3. Contributos

Espera-se, assim, que este trabalho constitua um importante contributo para o desenvolvimento do conhecimento nesta área.

Pela primeira vez em Portugal foi efectuada a avaliação da maturidade organizacional em gestão de projectos de SI/TI e em planeamento estratégico de TI. Também, foi analisada a correlação entre a maturidade em gestão de projectos de SI/TI com: maturidade organizacional em planeamento estratégico de TI; recursos humanos de TI por recursos humanos globais (%) e despesa em TI por despesa global (%).

8.4. Trabalho Futuro

Em suma, mais do que um projecto acabado, este trabalho deve ser encarado como uma etapa de um processo de investigação que deverá ser completado por outros subsequentes: dado a complexidade e abrangência do tema.


Assim, são aqui tecidas algumas recomendações de possível trabalho futuro, com o objectivo de dar continuidade ao trabalho iniciado, complementando-o ou adaptando-o a novos enquadramentos:

1. Definição de um conjunto de recomendações para permitir aumentar o nível de maturidade organizacional em gestão de projectos de SI/TI, bem como aumentar a taxa de sucesso dos projectos na Administração Pública;

2. Avaliação da Maturidade Organizacional em Gestão de Projectos na Administração Pública - Autarquias Locais e no Sector Privado.

Isto é, aplicar o estudo efectuado neste trabalho a um conjunto mais vasto de organizações. Pois, o trabalho aqui iniciado apenas permitiu uma avaliação das 37 entidades pertencentes aos Serviços Integrados e aos Serviços e Fundos Autónomos. Não permitindo efectuar um diagnóstico da Administração Pública em Geral. De forma a verificar se os resultados eram semelhantes aos apresentados neste trabalho;

3. Avaliar a Maturidade Organizacional em Gestão de Projectos de SI/TI na Administração Publica – Serviços Integrados e Serviços e Fundos Autónomos - utilizando outro(s) modelo(s) de avaliação da maturidade organizacional em gestão de projectos.

O objectivo é verificar se com o(s) outro(s) modelo(s) – como por exemplos: Capability Maturity Model Integration (CMMI); Project Management Maturity Model (PMMM); Organization Project Management Maturity Model (OPM3) - os resultados são semelhantes;

4. Avaliar as competências dos gestores de projectos de SI/TI da Administração Pública.

Conforme foi possível verificar através da revisão da literatura (capítulo 3) as competências do gestor do projecto e maturidade da organização em gestão de projectos afectam o desempenho dos projectos. Dado a amplitude do trabalho e do objecto em causa não foi possível efectuar esta avaliação no decurso deste trabalho;

5. Avaliar o desempenho dos projectos de SI/TI na Administração Pública. Verificar se existe uma correlação entre o sucesso e a maturidade, tal com é referido pelo PMI.

Conforme foi possível verificar através da revisão da literatura (capítulo 4) não existe uma definição padronizada de projecto de sucesso nem uma metodologia aceite para medição. Assim, cabe(rá) ao autor definir as variáveis a avaliar.


Referências

[Agarwal et al., 2006]

Agarwal, Nitin; Rathod, Urvashi; ―Defining Success for Software projects: An exploratory relation‖; International Journal of Project Management 24 (2006) 358-370.

[Amaral, 1994] Amaral, Luís; ―PRAXIS - Um Referencial para o Planeamento de Sistemas de Informação‖, 1994.

[António Miguel, 2003]

Miguel, António; ―Gestão de Projectos de Sotware‖; FCA – Editora de Informática, ISBN: 972-722-352-4, 2003.


Miguel, António; ―Gestão Moderna de Projectos – Melhores Ténicas e Práticas‖; FCA – Editora de Informática, ISBN: 978-972-722-502-6, 2006.


Miguel, António; ―Gestão Moderna de Projectos‖; FCA – Editora de Informática, ISBN: 973-972-722-506-6, Abril 2006.

[Atkinson, 1999] Atkinson, Roger; ―Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria‖, International Journal of Project Management Vol. 17, No. 6, pp. 337-342, 1999

[Baccarini, 1999] Baccarini, D; ―The Logical Framework Method for Defining Project Success‖; Project Management Journal, vol. 30, no. 4, pp. 25-32, 1999.

[Belassi and Tukel, 1996]

Bellassi, Walid; Tukel, Oya Icmeli; ―A new framework for determining critical success/failure factors in projects‖, Internacional Journal of Project Management Vol. 14. Nº 3, pp. 141-151, 1996.

[Boehm, 2000] Boehm, Barry; ―Project Termination doesn’t equal project failure‖; Software Management, Setptember 2000.

[Bressan, 2000] Bressan, Flávio ―O Método do Estudo de Caso‖, Volume 1, Número 1, Administração On Line, 2000, ISSN: 1517-7912.

[Bryman e Cramer, 2003]

Bryman, Alan; Cramer, Duncan; ―Análise de Dados em Ciências Sociais: Introdução às Técnicas Utilizando o SPSS para Windows‖, celta editora, 2003, ISBN – 972-774-169-X.

[Burgess, 1997] Burgess, Robert G.; ―A Pesquisa de Terreno – Uma Introdução‖; Celta Editora, 1997, ISBN: 972-8027-43-5.

[Chan et al., 2004] Chan, Albert P.C.; Chan, Ada P.L.; ―Key performance indicators for measuring construction Success‖, Benchmarking: An International Journal, Vol. 11, nº 2, pp- 203-221. Disponivel em www.emeraldinsigh.com/1463-5771.htm

[CMMI, 2006] CMMI Product Team; ―CMMI for Development, Version 1.2, CMU/SEI-2006-TR-008, Improving process for better products‖; Pittsburgh, PA: 15213-3890; Software Engineering Institute; August 2006.

[Cooke-Davies, Cooke-Davies; ―The ―real‖ success factors on projects‖, International

http://www.emeraldinsigh.com/1463-5771.htm


2002] Journal of Project Management, 20 (2002), 185-190.

[Cunha J., 2007] Cunha, J. Falcão; ―Sistemas de informação, Modelação do Conhecimento e Bases de Dados‖, disponível na http://paginas.fe.up.pt/~sibd/SIfiles/SCMIBD_Capitulo%201%20PSI.pdf; acedida em 4/03/2007.

[DeLone e McLean, 2003]

DeLon, William H.; McLean, Ephraim R.;―The DeLone and McLean Modelo of Information Systems Success: A Ten-Year Updade‖,Journal of Management Information Systems / Spring 2003, Vol. 19, No. 4, pp. 9–30.

[Dvir et al., 1998] Dvir, D.; Lipovetsky, S.; Shenhar, A.; Tishler, A. ―In search of project classification: a non-universal approach to project success factors‖, Elsevier Science B.V., (1998), 915-935.

[Fortune et al., 2006]

Fortune, Joyce; White, Diana White; ―Framing of project critical success facores by a systems model‖; International Journal of Project Management 24 (2006) 52-63.

[IGF, 2008] Inspecção-Geral de Finanças ―Caracterização da Despesa em Tecnologias da Informação e Comunicação (TIC), entre 2005 e 2007, na Administração Directa e Indirecta do Estado‖; Relatório nº 1290/2008.

[INA, 2007] Instituto Nacional de Administração, I.P; Documentação do curso ―Formação de Gestão de Projectos‖, 2007.

[ISACA, 2006] Information Systems Audit and Control Association; ―Norma de Auditoria de SI: Documento S12 Materialidade da Auditoria‖, 2006

[ITIG, 2007] IT Governance Institute, ―CobiT 4.1, Framework, Control objectives, Management Guidelines, Maturity Models‖; printes in the United States of America‖, 2007, ISBN: 1-933284-72-2.

[ITIG, 2007a] IT Governance Institute, ―IT Assurance Guide: using CobiT‖; printes in the United States of America‖, 2007, ISBN: 1-933284-74-9.

[ITIG-MyCobiT, 2007a]

MyCobiT; ―General Templete‖; CobiT Online 4.1, 2007.

[ITIG-MyCobiT, 2007b]

MyCobiT; ―Control Pratice Template‖; CobiT Online 4.1, 2007.

[ITIG-MyCobiT, 2007c]

MyCobiT; ―Assurance Step Template‖; CobiT Online 4.1, 2007.

[ITIG-MyCobiT, 2007d]

MyCobiT; ―Control Objectives Assessmente Forms‖; CobiT Online 4.1, 2007.

[Lim e Mohamed, 1999]

Lim, C.S; Mohamed, M Zain; ―Criteria of project Success: an exploratory re-examination‖, International Journal of Project Management, Vol. 17, nº4, pp-243-247, 1999.

[Lipovetsky et al., 1997]

Lipovetsky, Stan; et al; ―The relative importance of project success dimensions‖, Backwell Publishers Lda. 1997.

[Martins] Robert, K. Yin; ―Case Study Research: design and methods‖.

http://paginas.fe.up.pt/~sibd/SIfiles/SCMIBD_Capitulo%201%20PSI.pdf

http://paginas.fe.up.pt/~sibd/SIfiles/SCMIBD_Capitulo%201%20PSI.pdf


Tradução e síntese: Prof. Ricardo Lopes Pinto, Adaptação: Prof. Gilberto de Andrade Martins.

[Moreira, 1994] Moreira, Carlos Diogo; ―Planeamento e Estratégias da Investigação Social‖; Universidade Técnica de Lisboa – Instituto Superior de Ciências Sociais e Politicas – Lisboa, 1994.

[O’Connor, 1993] O’Connor, D. Anne, ―Successful strategic information systems planning‖, Joumal of information science, 3 p. 71-83 (1993).

[Paulk Mark C. et al., 1993]

Paulk, Mark C.; Curtis, Bill; Chrissis, Mary Beth; Weber, Charles V.; ―Capability Maturity Modelfor Software. Version 1.1. Technical report CMU/SEI-93-TR-24‖; Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 1993. Desponível em: http://www.sei.cmu.edu/pubs/documents/93.reports/pdf/93tr024.pdf

[Paulk, M et al., 1995]

Paulk, M., Curtis, B., Chrissis, M., Weber, c., The Capability Maturity Model for Software: Guidelines for Improving The Software Process, Addison-Wesley, Reading, MA, 1995.

[Pinto, Jeffery k. e Manterl, Samuel J., 1990]

Pinto, Jeffery k.; Manterl, Samuel J.; ―The causes of project Failure‖, IEE transactions on Enginneering Management, Vol. 37, nº 4, November 1990.

[Pinto, Jeffery K., 1998]

Pinto, Jeffery K.; ―Understanding the role of politics in successful project management‖, International Journal of Project Management 18 (2000) 85±91, November 1998.

[PMBOK, 2000] Project Management Institute; ―A Guide to the Project Management Body of Knowledge (PMBOK® Guide)‖, 2000 Edition, Project Management Institute, Inc., Newtown Square, Pennsylvania, 2000.

[PMBOK, 2004] Project Management Institute; ―A Guide to the Project Management Body of Knowledge (PMBOK® Guide)‖, Third Edition, Project Management Institute, Inc., Newtown Square, Pennsylvania, 2004.

[PMCD, 2002] Project Management Institute; ―Project Manager Competency Development (PMCD) Framework‖, Project Management Instituite, Newtown Square, Pennsylvania USA, 2002.

[PMI, 2009] Descrição do PMI. Disponível em: http://www.pmipe.org.br/web/br/pmi.php?conteudo=1 e

http://www.pmi.org/aboutus/Pages/Default.aspx acedido em 24/Fev/2009.

[Santos et al., 2006]

Santos, Diogo; Moraes, Renato; ―Avaliação do desempenho de projectos de Data Warehouse‖; Journal of Project Management & Innovation, Vol. 1, No. 3, 2006.

[Senhar et al., 2001]

Senhar, Aaron J.; Dvir, Dov; Levy, Ofer; Maltz, Alan C.; ―Project Success: a Multidimensional Strategic Conceptual‖; Pergamon, Long Range Planning 34, pp. 699-725, 2001.

[Shenhar et al., Shenhar, J. Aaron; Dvir, Dov; Levy, Ofer, Maltz, Alan C. ―Project Success: A Multidimensional Strategic Concept‖, Long Range

http://www.sei.cmu.edu/pubs/documents/93.reports/pdf/93tr024.pdf

http://www.sei.cmu.edu/pubs/documents/93.reports/pdf/93tr024.pdf

http://www.pmipe.org.br/web/br/pmi.php?conteudo=1

http://www.pmi.org/aboutus/Pages/Default.aspx%20acedido%20em%2024/Fev/2009

http://www.pmi.org/aboutus/Pages/Default.aspx%20acedido%20em%2024/Fev/2009


2001] Planning 34 (2001) 699-725.

[Silva e Pinto] Silva, Augusto Santos; Pinto, José Madureira; ―Metodologias das Ciências Sociais‖, Biblioteca das Ciências do Homem, Edições Afrontamento.

[Standish Group International, 2001]

Standish Group Internacional, ―Extreme Chaos‖, 2001.

[Standish Group International, 2004]

Standish Group Internacional, ―The Lastest Chaos Report in Project Management‖, 2004.

[Stuckerbruck, 1981]

Stuckenbruck, Df. L. c., Editor, "The Implementation of Project Management‖, Project Management Institute, PA, Wiley, 1981, pp2-3.

[Sykes, 1990] Sykes, Vanda; ―Validity and Reliability in Qualitative Marketing Research: a Review of Literature‖; Journal of the Market Research Society, Vol. 32, nº 3, July, 1990.

[Tasmanian, 2005] Tasmanian Government, ―Project Management Guidelines‖, Version 6.0 - March 2005, Inter Agency Policy and Projects Unit Government Information and Services Division Department of Premier and Cabinet Tasmania. Disponível em: http://www.egovernment.tas.gov.au/__data/assets/dpac_file_desc/0005/13478/pman-reso-open-tgpmg-6.0-full.pdf

[Teo e Ang, 1999] Thompson S.H. Teo, James S.K. Ang, ―Critical success factors in the alignment of IS plans with business plans‖, International Journal of Information Management 19 (1999) 173-185.

[Toffer-Alvin, 1981]

Toffer-Alvin, ―The Third Wave‖, Pan Books, 1981, ISBN 0-330- 26337-4

[UMIC, 2005] Administração Pública Central 2005, Inquérito à Utilização das Tecnologias da Informação e da Comunicação, Dezembro de 2005.

[UMIC, 2005C] Camaras Municipais 2005, Inquérito à Utilização das Tecnologias da Informação e da Comunicação, Dezembro de 2005.

[UMIC, 2005M] Região Autónoma da Madeira, Inquérito à Utilização das Tecnologias da Informação e da Comunicação na Administração Pública Regional 2005, Dezembro 2005.

[UMIC, 2006] Administração Pública Central 2006, Inquérito à Utilização das Tecnologias da Informação e da Comunicação, Dezembro de 2006.

[Wateridge, 1995] Wateridge, John; ―IT projects: a basis for success‖; International Journal of Project Management Vol. 13, No. 3, pp. 169-172, 1995.

[Wateridge, 1998] Wateridge, John; ―How Can IS/IT projects be measured for Success‖; International Journal of Project Management Vol. 16, No. 1, pp. 59-63, 1998.

[Westhuizen et al., Westhuizen, Van Der; Fitzgerald, Edmon P.; ―Defining and measuring project success‖; Proceedings of the European Conference on IS

http://www.egovernment.tas.gov.au/__data/assets/dpac_file_desc/0005/13478/pman-reso-open-tgpmg-6.0-full.pdf

http://www.egovernment.tas.gov.au/__data/assets/dpac_file_desc/0005/13478/pman-reso-open-tgpmg-6.0-full.pdf


2005] Management, Leadership, and Governance, Reading, UK, 2005.

[WWPMM, 2002] ―Guide to using WWPMM for Program Management‖, ―IBM Worldwide Project Management Method (WWPMM)‖, 2002

[Yates & Maanen, 2001]

Yates, JoAnne; Maanen, John Van; ―Information Technology and Organizational Transformation‖; Sage Publications, Inc., ISBN 0-07619-2301-2, 2001.

[Yeo, 2002] Yeo, K.T.; ―Critical failure factors in information system projects‖, International Journal of Project Management, 20 (2002), pp. 241-246

[Yin, 1989] Yin, Robert K. ―Case Study Research – Design and Methods‖, Second Edition, Sage Publications, ISBN: 0-8039-5662-2, 1989.


Anexo A: O Método de Estudo de Caso

Os métodos de pesquisa qualitativa foram desenvolvidos nas Ciências Sociais, para permitir aos investigadores estudar, perceber e explicar fenómenos sociais e culturais. Segundo Goode & Hatt (1969) ―o método de Estudo de Caso é considerado um tipo de análise qualitativa‖, citado por Bressan (2000). A necessidade de utilizar a estratégia de pesquisa ―Estudo de Caso‖ nasce da premência de entender um fenómeno social complexo.

O método de Estudo de Caso teve origem nas Ciências Políticas, na Sociologia, Psicologia, na avaliação de estudos urbanos e em outras Ciências Sociais, nas disciplinas que possuem uma forte orientação para a prática como a Administração, na elaboração de testes e dissertações com o objectivo de desenvolver uma análise profunda de um ou múltiplos casos.

As estratégias de pesquisa usadas em Ciências Sociais podem ser: a experimental; survey (levantamento); histórica; análise de informações de arquivos (documental) e estudo de caso; podendo ser usadas com vários propósitos: exploratório; descritivo; explanatório (causal). Sendo, contudo, mais frequente os estudos de caso com propósitos exploratório e descritivo, citado por Gilberto de Andrade Martins [Martins]. A estratégia de pesquisa dependerá do tipo de questão da pesquisa, do grau de controlo que o investigador tem sobre os eventos, ou do foco temporal (eventos contemporâneos X fenómenos históricos).

Opta-se pelo Estudo de Caso em situações em que a questão visa o ―como‖ e o ―porquê‖, quando o investigador tem um diminuto controlo sobre os acontecimentos ou, mesmo, quando se trata de fenómenos contemporâneos em contexto de vida real. Quando a pergunta de pesquisa é da forma ―como?‖ ou ―porquê? as estratégias poderão ser: estudo de caso, pesquisa histórica ou experimental.

A pesquisa qualitativa envolve o uso de fontes de dados qualitativos, tais como: entrevistas; questionários; documentos (publicados e não publicados); relatórios internos; cartas; faxes ou dados resultantes da participação /observação (trabalho de campo) - a sua escolha influenciará o modo como o investigador recolhe dados.

A.1 Definição do Método de Estudo de Caso

O Método do Estudo de Caso ― ... não é uma técnica específica. É um meio de organizar dados sociais preservando o carácter unitário do objecto social estudado‖ (Goode & Hatt, 1969, p.422). De outra forma, Tull (1976, p. 323) afirma que ―um estudo de caso refere-se a uma análise intensiva de uma situação particular‖ e Bonoma (1985, p. 203) classifica que o ―estudo de caso é uma descrição de uma situação de gestão‖, citado por citado por Bressan (2000).

Yin (1989, p.23) define o Estudo de Caso como sendo uma estratégia de inquirição empírica que:

Investiga um fenómeno contemporâneo, dentro do seu contexto da vida real; quando as fronteiras entre o fenómeno e o contexto não são muito claras; onde múltiplas fontes de evidência (informação) são utilizadas.

Esta definição de Yin ajuda-nos a compreender e a distinguir o método do estudo de caso de outras estratégias de pesquisa como o método histórico e a entrevista em profundidade, o método experimental e o survey, citado por Bressan (2000).


A.2 O Uso do Método de Estudo de Caso

Ao comparar o Método do Estudo de Caso com outros métodos Yin (1989) afirma que, para se definir o método a ser usado, é preciso analisar as questões que são colocadas pela investigação. De modo específico este método é adequado para responder às questões "como" e '"porquê", que são questões explicativas e tratam de relações operacionais, que ocorrem ao longo do tempo mais do que frequências ou incidências.

Yin (1989) dá preferência ao do Estudo de Caso quando estuda eventos contemporâneos, em situações onde os comportamentos relevantes não podem ser manipulados, onde é possível fazer-se observações directas e entrevistas sistemáticas. Apesar de ter pontos em comum com o método histórico o Estudo de Caso caracteriza-se pela "... capacidade de lidar com uma completa variedade de evidências – documentos, artefactos, entrevistas e observações." [Yin, 1989, p. 19]. Este método (e os outros métodos qualitativos) é útil segundo Bonoma (1985, p. 207), ―... quando um fenómeno é amplo e complexo, onde o corpo de conhecimentos existente é insuficiente para permitir a proposição de questões causais e quando um fenómeno não pode ser estudado fora do contexto no qual ele naturalmente ocorre‖, citado por Bressan (2000).

Os objectivos do método de Estudo de Caso, segundo McClintock et al. (1983, p. 150), ―...são (1) capturar o esquema de referência e a definição da situação de um dado participante ... (2) permitir um exame detalhado do processo organizacional e (3) esclarecer aqueles factores particulares ao caso que podem levar a um maior entendimento da causalidade‖, citado por Bressan (2000).

Bonoma (1985), ao tratar dos objectivos da recolha de dados, coloca como objectivos do Método do Estudo de Caso não a quantificação ou a enumeração, ―... mas, ao invés disto (1) descrição, (2) classificação (desenvolvimento de tipologia), (3) desenvolvimento teórico e (4) o teste limitado da teoria. Em uma palavra, o objectivo é compreensão‖ (p. 206), citado por Bressan (2000).

Yin (1989) apresenta sinteticamente quatro aplicações para o Método do Estudo de Caso:

1. Para explicar ligações causais nas intervenções na vida real, que são muito complexas para serem abordadas pelos surveys ou pelas estratégias experimentais;

2. Para descrever o contexto da vida real no qual a intervenção ocorreu;

3. Para fazer uma avaliação, ainda que de forma descritiva, da intervenção realizada;

4. Para explorar situações onde as intervenções avaliadas não possuem resultados claros e específicos.

Propostas de Yin (1989) e Goode & Hatt (1967) para se obter um bom estudo de caso:

1. Desenvolver um plano de pesquisa que considere os perigos ou críticas. Por exemplo, com relação ao sentimento de certeza pode-se usar um padrão de amostra apropriado, pois, ― sabendo que sua amostra é boa, ele tem uma base racional para fazer estimativas sobre o universo do qual ela é retirada‖ [Goode & Hatt, 1989, p. 428];

2. As generalizações fazem-se em relação às proposições teóricas e não para populações ou universos [Yin, 1989];

3. Planear a utilização da ―... técnica do código qualitativo para traços e factores individuais que são passíveis de tais classificações. Se usar categorias como ―egoísta‖ ou ―ajustado‖... desenvolverá um conjunto de instruções para decidir se um determinado caso está dentro


da categoria e estas instruções devem ser escritas de maneira que outros cientistas possam repeti-las‖ [Goode & Hatt, 1969, p. 428-429]. Estes autores recomendam que as classificações feitas sejam analisadas por um conjunto de colaboradores que actuarão como ―juízes da fidedignidade mesmo das classificações mais simples‖[ibid., p. 429];

4. Evitar narrações e relatórios extensos porque desencorajam a leitura e a análise do estudo do caso;

5. Proceder a selecção e treino criteriosos, dos investigadores e assistentes, para assegurar o domínio das habilidades necessárias à realização de Estudo de Caso.

A.3 O Plano de Estudo de Caso

Yin (1989) aborda os procedimentos para a elaboração de um plano de pesquisa para o Estudo de Caso como sendo ―a sequência lógica que liga os dados empíricos às questões iniciais de estudo da pesquisa e, por fim, às suas conclusões‖ (p. 27), citado por Bressan (2000).

Isto significa que a elaboração do projecto de pesquisa tem uma influência directa sobre os resultados a serem obtidos e a validade das conclusões tiradas do trabalho - servindo de guia para todo o trabalho do investigador.

No que se refere ao Projecto de Pesquisa, para utilização do Estudo de Caso, cinco componentes (Yin, 1989) são importantes (e devem ser elaborados com cautela e rigor), pois, darão sustentação ao processo de pesquisa e guiarão o investigador no seu trabalho, ajudando-o a manter-se no rumo pretendido. Os cinco componentes são:

As perguntas do estudo – o método indicado para responder às perguntas ―como‖ e ―porquê‖, que são questões explicativas, nos estudos que tratam de relações operacionais que ocorrem ao longo do tempo mais do que frequências ou incidências e de eventos contemporâneos, em situações onde os comportamentos relevantes não podem ser manipulados, mas, onde é possível fazer-se observações directas e entrevistas sistemáticas, a primeira tarefa a ser empreendida é a clarificação precisa da natureza das questões - tarefa importante pois norteará todo o trabalho a ser realizado;

As proposições do Estudo - As proposições dizem respeito ao que será examinado no alvo do trabalho e a sua definição ajudará a procurar evidências relevantes. De acordo com Yin (1989) sem estas proposições ―um investigador pode sentir-se tentado a recolher ―tudo‖ o que é impossível de ser feito‖(p. 30). Alternativamente o investigador estabelece o propósito para o estudo e defini os critérios pelos quais o sucesso da investigação será analisado;

As unidades de análise – estão relacionadas com a definição do que o caso é - pode ser um indivíduo, uma decisão, um programa, uma implantação de um processo e uma mudança organizacional. A definição da unidade de análise está ligada à maneira pela qual as questões de estudo foram definidas;

A lógica que liga os dados às proposições e os Critérios para a Interpretação dos Dados - Estes dois componentes, o quarto e o quinto, representam a análise no Estudo de Caso e o projecto de pesquisa é a base sobre a qual esta análise será feita, relacionando-se as informações obtidas com as proposições estabelecidas, no início da elaboração do projecto de pesquisa.

Os critérios para interpretação dos dados, as análises e inferências, são feitas por analogia de situações, buscam responder às questões ―porquê‖ e ―como‖ inicialmente formuladas


(Campomar, 1991), citado por Bressan (2000). Ao desenvolver estes componentes do Projecto de Pesquisa o investigador é forçado a construir uma teoria inicial relativa ao estudo a ser empreendido. Esta teoria deve ser formulada antes do início da recolha de dados, pois, ela irá ajudar a cobrir de forma incremental as questões, as proposições ou o propósito do estudo, as unidades de análise, possibilitando a ligação dos dados às proposições e fornecerá os critérios para a análise dos dados [Yin, 1989]. Ao proceder desta maneira o investigador terá um roteiro objectivo e habilitado para orientá-lo durante todo o processo de realização do estudo, que lhe dará direcção para a definição dos dados a serem recolhidos, e para a definição das estratégias para a sua análise, possibilitando-lhe fazer contribuições/generalizações para a teoria maior [Yin, 1989].

A.4 Critérios para Avaliar a Qualidade do Estudo de Caso

Considerando que o projecto de pesquisa deve ser uma proposição lógica, a sua qualidade deve ser analisada também por critérios lógicos e, de acordo com Yin (1989), por quatro testes referentes a Validade e a Confiabilidade.

1. Validade

De acordo com Sykes (1990) o termo validade é usado numa grande variedade de sentidos nos debates sobre a pesquisa quantitativa, mas, o seu sentido, refere-se ao tipo e precisão da informação obtida das amostras individuais, quer sejam indivíduos ou grupos. A avaliação da validade deve ser feita à luz do propósito do trabalho de investigação.

A validade pode ser:

Validade Teórica – os métodos de recolha de dados têm validade teórica quando os seus procedimentos são justificados em termos de teorias estabelecidas como as Psicológicas, Sociológicas etc. [Sykes, 1990];

Validade de Constructo – diz respeito ao estabelecimento de medidas de operação correctas para os conceitos a serem estudados [Yin, 1989] e fluí de algum constructo teórico (Sykes, 1989);

Validade Interna – refere-se ao estabelecimento de relações causais [Yin, 1989] e resulta de estratégias que objectivem eliminar a ambiguidade, a contradição, embutidas nos detalhes, e do estabelecimento de fortes conexões entre os dados [Sykes, 1990];

Validade Externa – estabelece o domínio para o qual as descobertas do estudo podem ser generalizadas [Yin, 1989] - que podem ser obtidas pela replicação da pesquisa;

Validade Instrumental ou de Critério – baseada na validade atribuída aos procedimentos usados na pesquisa. Contudo, nenhum procedimento/método pode ser considerado válido 'a priori', mas, pode-se buscar a comparabilidade ou a compatibilidade das descobertas, usando-se o método da triangulação para se fazer esta análise [Sykes, 1990];

Validade Consultiva – refere-se à possibilidade de se consultar os envolvidos no processo de pesquisa – entrevistadores, observadores, respondentes, entrevistados – para se obter informações sobre sua precisão, completude, relevância, etc. dos dados obtidos [Sykes, 1990].


2. Fidedignidade

A fidedignidade refere-se à consistência dos dados [Sykes, 1990] e à repetitibilidade dos resultados em que se repetindo os mesmos procedimentos, em situação semelhante, um outro investigador chegará às mesmas descobertas e conclusões [Yin, 1989].

Para que isto seja possível o procedimento do estudo a ser repetido tem de estar devidamente documentado e, para facilitar o processo, o investigador deve projectar o maior número de estágios possíveis.

A.5 Tipos de Estudo de Caso

Yin (1989) apresenta quatro tipos de estudos de casos, resultantes de uma matriz de dupla entrada, considerando – vide tabela 51:

O número de casos envolvidos – singular ou múltiplos;

A unidade de análise – holístico (uma unidade de análise) ou incluso (várias unidades de análise).

Singular Múltiplo

Holístico (uma unidade de análise) Tipo 1 Tipo 3

Incluso (várias unidades de análise) Tipo 2 Tipo 4

Tabela 51 – Tipos de Estudos de Casos (Yin, 1989).

Fonte: Autor.

A.6 O Protocolo do Estudo de Caso

O Protocolo do Estudo de Caso contém os procedimentos e as regras gerais que devem ser seguidas na aplicação e no uso dos instrumentos. Segundo Yin (1989) este protocolo, ou manual, deve conter:

Uma visão geral do projecto de estudo de caso – descrição, objectivos, problemas, questões do estudo de caso e leituras relevantes sobre os tópicos a serem investigados;

Os procedimentos do trabalho de campo – credenciais, formas de acesso aos locais de estudo e calendarização e fontes de informação;

As perguntas do estudo de caso – as questões que o investigador deve ter em mente, os locais, as fontes de informação, os formulários para o registo dos dados e as potenciais fontes de informação para cada questão;

Um Guião para o relatório de estudo de caso – estrutura e bibliografia.

O protocolo que está associado à validade interna do estudo visa:

Harmonizar as actividades de recolha de dados;

Prever e preparar alternativas à calendarização (tipo plano B).


A cada caso corresponde um protocolo, ou seja, o protocolo é indissociável de um caso particular.

A.7 Condução do Estudo de Caso

Como os dados são recolhidos sob condições de ambiente não controlado, isto é, em contexto real, é o investigador que deve adaptar seu plano de recolha de dados e informações à disponibilidade dos entrevistados. Por outras palavras: é o entrevistador que se deve introduzir no mundo do objecto, e não o contrário, como ocorre com as estratégias de pesquisa em ambiente controlado. Isso significa que o comportamento do pesquisador pode sofrer restrições. Por isso, é importante ter em mente que não se poderá contar com instrumentos rígidos (tipo questionário com questões de múltipla escolha). Pelo contrário, o mais indicado é formular directrizes sobre o comportamento do investigador em campo.

Sendo assim, sugere-se que sejam enfatizadas as seguintes tarefas nos procedimentos de campo:

Conseguir acesso à organização-chave e/ou aos entrevistados-chave;

Munir-se de recursos suficientes para o trabalho em campo (material, local p/ anotações etc.);

Desenvolver um procedimento para receber ajuda ou orientação de outros investigadores;

Criar um cronograma relacionando as actividades de recolha de dados em períodos específicos de tempo;

Preparar-se para a ocorrência de acontecimentos inesperados (mudança na disponibilidade dos entrevistados, etc.)

O método de Estudo de Caso obtém evidência a partir de seis fontes de dados:

Documentos – A documentação, pela sua própria característica, é uma importante fonte de dados e nela as informações podem tomar diversas formas como cartas, memorandos, agendas, actas de reuniões, documentos administrativos, estudos formais, avaliações de plantas e artigos dos Média. O uso da documentação deve ser cuidadoso pois, segundo Yin (1989), esta não pode ser aceite como registo literal e preciso dos acontecimentos ocorridos, o seu uso deve ser planeado para que sirva para corroborar e aumentar as evidências vindas de outras fontes. Ela ajuda-nos a estabelecer com clareza os títulos e os nomes das organizações mencionadas, que inferências podem ser feitas a partir da análise da qualidade dos registos e dos documentos, como por exemplo, definir para quem determinados memorandos foram enviados e assim por diante [Yin, 1989, p. 86].

Apresentam-se a seguir, em baixo, os Critérios de Avaliação de documentos de Scott (1990).

Autenticidade Segurança e Autoria

Credibilidade Sinceridade e Precisão

Representatividade Sobrevivência e Disponibilidade

Significado Significado Literal e Compreensão Interpretativa

Tabela 52 – Critérios de Avaliação de Documentos (Scott, 1990).

Fonte: Scott 1990 (citado por Moreira, 1994).


Registos de Arquivos – Os dados arquivados, em computador por exemplo, podem ser relevantes para muitos Estudos de Caso. Estes dados podem ser [Yin, 1989] dados de serviço, como número de clientes, dados organizacionais - orçamentos, mapas e quadros - dados geográficos, lista de nomes, dados de levantamentos, dados pessoais - como salários, listas de telefone - que podem ser usados em conjunto com outras fontes de informações tanto para verificar a exactidão como para avaliar dados de outras fontes. Um cuidado a ser tomado é que apesar de estes dados geralmente serem precisos, sua existência, por si só, não são garantia de precisão e acurácia. Por causa disto é sempre necessário que o investigador faça cruzamentos antes de chegar a conclusões.

Entrevista - Esta é uma das fontes de dados mais importantes, para os Estudos de Caso, apesar de haver uma associação usual entre a entrevista e metodologia de survey [Yin, 1989]. A entrevista, dentro da metodologia do Estudo de Caso, pode assumir várias formas:

o Entrevista de Natureza Aberta-Fechada – onde o investigador pode solicitar aos respondentes chave a apresentação de factos e de opiniões a eles relacionados;

o Entrevista Focada – onde o respondente é entrevistado por um curto período de tempo e pode assumir um carácter aberto-fechado ou tornar-se conversacional o investigador deve preferencialmente seguir as perguntas estabelecidas no protocolo da pesquisa;

o Entrevista do tipo Survey – que implicam questões e respostas mais estruturadas.

De forma geral, as entrevistas são uma fonte essencial de evidências para o Estudo de Caso [Yin, 1989], pois, os estudos de caso em pesquisa social lidam geralmente com actividades de pessoas e grupos. O problema é que isto pode sofrer a influência dos observadores e entrevistadores e, por isto, podem ser reportadas e interpretadas de acordo com as idiossincrasias de quem faz e relata a entrevista. Por outro lado, os respondentes bem informados podem fornecer importantes insights sobre a situação. Ao considerar-se o uso das entrevistas, portanto, deve-se cuidar para que isto não interfira nos resultados, para isso, providencia-se com treino e habilitação os investigadores envolvidos.

Observação Directa – Ao visitar o local de estudo, um observador preparado pode fazer observações e recolher evidências sobre o caso em estudo. ―Estas evidências geralmente são úteis para prover informações adicionais sobre o tópico em estudo.‖ [Yin, 1989, p. 91] Para se aumentar a fidedignidade das observações, além de se ter roteiro definido no protocolo, pode-se designar mais de um observador e, após as observações, comparar os resultados das observações relatadas para se suprimir discrepâncias existentes.

Observação Participante – Este é um tipo especial de observação na qual o observador deixa de ser um membro passivo, pode assumir vários papéis na situação do caso em estudo, e pode participar e influenciar nos eventos em estudo. Este é um método que tem grande uso nas pesquisas antropológicas, sobre diferentes grupos culturais, e pode prover oportunidades para a recolha de dados que podem dar ao investigador acesso a eventos ou informações que não seriam acessíveis por outros métodos. O problema da observação participante é o investigador poder assumir posições ou advogar contra os interesses das práticas científicas recomendadas, pode assumir posições do grupo ou organização em estudo e pode ter problemas ao fazer anotações ou levantar questões sobre os eventos em perspectivas diferentes.

Artefactos Físicos – Os artefactos Físicos e Culturais também constituem uma fonte de


evidências, podem ser recolhidos ou observados como parte do estudo de campo, e podem fornecer informações importantes sobre o caso em estudo.

Ao elaborar o Plano de Pesquisa o investigador tem que estabelecer procedimentos que visem maximizar os resultados a serem obtidos, o que é possível com a utilização das seis fontes de evidência atrás referenciadas.

Para auxiliá-lo nesta tarefa, Yin (1989) recomenda a aplicação de três princípios:

Princípio do Uso de Múltiplas Fontes de Evidência - esta é uma característica dos Estudos de Caso, o uso de múltiplas fontes de evidência, que podem ajudar o investigador a abordar o caso de forma mais ampla e completa além de poder fazer cruzamento de informações e evidências;

Princípio da Criação de um Banco de Dados do Estudo de Caso – para se registar todas as evidências, dados, documentos e relatórios sobre o caso em estudo, e para torná-los disponíveis para consultas;

Princípio da Manutenção de uma Cadeia de Evidências - que deve ser seguido para melhorar a fidedignidade do Estudo do Caso tendo como objectivo explicitar as evidências obtidas para as questões iniciais, e como elas foram relacionadas às conclusões do estudo, servindo de orientação para observadores externos ou para aqueles que farão uso dos resultados do estudo.

O uso de múltiplas fontes de evidência permite investigar vários aspectos em relação ao mesmo fenómeno. As conclusões e descobertas ficam mais convincentes e apuradas já que advêm de um conjunto de corroborações. Além disso, os potenciais problemas de validade do estudo são atendidos, pois, será validado através da utilização das várias fontes de evidência.


Anexo B: Unidades de Análise

Unidades de análise seleccionada:

Tabela 53 – Unidades de Análise

Fonte: Autor.

Ministério Serviço Total %

MA MAS1 3,427,642.23 0.77%

Total 3,427,642.23 0.77%

MB MBS1 12,147,017.30 2.73%

MBS2 10,047,481.82 2.26%

MBS3 7,667,382.26 1.73%

Total 29.861.881,38 6,72%

MC MCS1 1,369,639.25 0.31%

MCS2 1,315,750.93 0.30%

Total 2,685,390.18 0.60%

MD MDS1 32,984,162.93 7.42%

MDS2 32,752,877.24 7.37%

MDS3 2,486,283.35 0.56%

MDS4 1,417,369.84 0.32%

Total 69,640,693.36 15.68%

ME MES1 5,115,559.00 1.15%

MES2 1,947,468.00 0.44%

MES3 1,789,642.18 0.40%

Total 8,852,669.18 1.99%

MF MFS1 28,037,527.60 6.31%

MFS2 12,581,484.13 2.83%

MFS3 12,260,668.03 2.76%

MFS4 9,279,610.60 2.09%

Total 62,159,290.36 7.68%

MG MGS1 1,036,401.74 0.23%

MGS2 969,609.00 0.22%

MGS3 958,951.39 0.22%

MGS4 953,294.98 0.21%

Total 3,918,257.11 0.88%

MH MHS1 1,069,964.00 0.24%

MHS2 950,654.26 0.21%

Total 2.020.618,26 0.45%

MI MIS1 3,560,787.00 0.80%

MIS2 1,153,682.51 0.26%

MIS3 1,035,955.65 0.23%

Total 5,750,425.16 1.29%

MJ MJS1 2,576,002.96 0.58%

MJS2 569,336.55 0.13%

Total 3,145,339.51 0.71%

MK MKS1 7,983,022.82 1.80%

Total 7,983,022.82 1.80%

ML MLS1 35,274,743.00 7.94%

MLS2 2,757,058.09 0.62%

MLS3 1,976,517.45 0.44%

Total 40,008,318.54 9.01%

MM MMS1 6,935,471.80 1.56%

MMS2 6,081,801.93 1.37%

MMS3 2,035,156.30 0.46%

Total 15,052,430.03 3.39%

MN MNS1 1,754,281.70 0.39%

MNS2 1,552,507.00 0.35%

Total 3,306,788.70 0.74%

MO MOS1 765,973.89 0.17%

MOS2 489,250.52 0.11%

Total 1,255,224.41 0.28%

Total da Amostra 257.998.027,23 51,76%


Anexo C: Análise do Classificador Económico

das Despesas SI/TI

O presente documento consubstancia os resultados da caracterização e análise do classificador económico das despesas públicas, realizada com o objectivo de avaliar quais as rubricas passíveis de serem utilizadas para a caracterização das despesas em SI/TI nos Serviços Integrados e Serviços e Fundos Autónomos.

Tendo como referencial a análise do Decreto-Lei nº 26/2002, de 14 de Fevereiro, da Resolução do Conselho de Ministros nº 181/2004, publicada no diário da Republica nº 298, de 22 de Dezembro, das informações nºs 32/2003, 38/2004 e 106/2005 emitidas pela Direcção-Geral do Orçamento, os principais resultados desta caracterização e análise são, em síntese, os seguintes:

Despesa com Aquisição de Comunicação

A partir de 2006, a rubrica 02.02.09 - «Comunicações» permite uma desagregação de despesas de comunicação.

1. Tal como refere na nota explicativa da rubrica 02.02.09 – «Comunicações», deverão classifica-se as despesas com telefones (instalações, aluguer, chamadas, mudanças e cargas de desinfectantes), telex, correios (nomeadamente, selos, telegramas, taxas de apartados e prémios de valores) e tráfego radiotelegráfico internacional. Incluem-se ainda os encargos com taxas e impulsos com ligação à internet para diversas utilizações, designadamente consultas do Diário da República, de sites institucionais, aquisição de bens e serviços, etc.

2. Por força da RCM nº 181/2004, publicada no Diário da República nº 298, de 22 de Dezembro, as aquisições com comunicações devem ser objecto de classificação económica nas rubricas com códigos que se indicam, atendendo ao tipo de bem ou serviços adquiridos: – 02.02.09.A0.00 – Acessos à Internet; – 02.02.09.B0.00 – Comunicações fixas de dados; – 02.02.09.C0.00 – Comunicações fixas de voz; – 02.02.09.D0.00 – Comunicações móveis; – 02.02.09.E0.00 – Outros serviços conexos de comunicações; – 02.02.09.F0.00 - Outros serviços de comunicações.

Despesa com Aquisição de Hardware

As despesas objecto de classificação económica nas rubricas com os códigos 07.01.07.Y0.A0 - «Equipamento de Informática – Hardware de Comunicações», 07.01.07.Y0.B0 - «Equipamento de Informática – Outros», 07.01.09.Y0.A0 – «Equipamentos administrativos – Hardware de Comunicações» e 07.01.10.Y0.A0 - «Equipamentos básicos – Hardware de Comunicações» dizem respeito apenas a hardware. Além disso, também são classificadas despesas com aquisição de Hardware nas rubricas com os códigos 07.01.09.Y0.B0 - «Equipamento administrativo – outros» e 07.01.10.Y0.B0 - «Equipamento básico – outros» conjuntamente com outras despesas.


3. Tal com refere na nota explicativa da rubrica 07.01.07 - «Equipamento de informática» (Decreto – Lei n.º 26/2002 de 14 de Fevereiro) deverão classifica-se as despesas com a aquisição de computadores, os terminais, as impressoras (hardware) e quaisquer outros bens44 que, assumindo características de bens de investimento, possam considerar-se como técnica, directa e exclusivamente ligados à produção informática.

4. Na rubrica 07.01.09 - «Equipamento administrativo» (Decreto – Lei n.º 26/2002 de 14 de Fevereiro) deverão classificar-se as despesas com o equipamento social e o mobiliário diverso. Como equipamento administrativo entende-se mobiliário, máquinas de calcular, impressoras, fotocopiadoras e demais equipamento de escritório. Como equipamento social entende-se equipamento de refeitório, postos médicos ou de primeiros socorros, de desporto ou equipamentos culturais, entre outros bens que sirvam aos funcionários fora do âmbito da relação profissional.

5. Na rubrica 07.01.10 - «Equipamento básico» (Decreto – Lei n.º 26/2002 de 14 de Fevereiro) deverão incluir-se as despesas com instrumentos, máquinas, instalações e outros bens, com excepção dos indicados na rubrica 07.01.11 - «Ferramentas e utensílios», com os quais se realiza a extracção, transformação e elaboração dos produtos ou a prestação de serviços. Compreende também os gastos adicionais com a adaptação de maquinaria e de instalações no desempenho das actividades próprios do organismo.

6. Por forma a dar cumprimento ao estipulado na RCM nº 181/2004, publicada no Diário da República nº 298, de 22 de Dezembro, deve-se proceder a desagregação da classificação económica das rubricas supra citada, da seguinte forma:

– 07.01.07.Y450.A0 – Hardware de comunicações; – 07.01.07.Y0.B0 – Outros46; – 07.01.09.Y0.A0 – Hardware de comunicações; – 07.01.09.Y0.B0 – Outros; – 07.01.10.Y0.A0 – Hardware de comunicações; – 07.01.10.Y0.B0 – Outros.

Despesas com aquisição de Software

A partir de 2006, a rubrica 07.01.08 - «Software informático» permite uma desagregação de despesas em software de comunicações e outras.

7. Na rubrica 07.01.0847 – «Software informático» (Decreto-Lei n.º 26/2002, de 14 de Fevereiro) – deverão engloba-se as despesas com a aquisição dos produtos informáticos.

44 Tal como, por exemplo: HUB.

45 Y - Corresponde à alínea relativa ao sector institucional, a utilizar nos termos do DL nº 26/2002, de 14 de Fevereiro: A – Administração central – Estado; B – Administração central – Serviço e fundos autónomos; C – Administração regional; D – Administração local – Continente; E – Administração local – Regiões Autónomos; F – Segurança Social; G – Instituições sem fins lucrativos.

46 De acordo com a informação nº 38/2004 da DGO, a ―aquisição de um computador – a respectiva despesa deverá ser classificada em «equipamento básico» se a sua utilização concorrer para a consecução da actividade principal prosseguida pelo serviço, ou em «equipamento administrativo» se a sua utilização se destinar a actividades de carácter administrativo (complementares da actividade principal), ou ainda em «equipamento de informática» se visar o suporte da rede informática da entidade‖.

47 Saliente-se que, de acordo com a DGO (informação nº 38/2004) a rubrica 07.01.08 «Software informático» não faz ―qualquer distinção entre o software de base e o de aplicação‖.


8. Por forma a dar cumprimento ao estipulado na RCM nº 181/2004, publicada no Diário da República nº 298, de 22 de Dezembro, deve-se proceder a desagregação da classificação económica das rubricas supra citada, da seguinte forma:

– 07.01.08.Y0.A0 - Software de comunicações;

– 07.01.08.Y0.B0 – Outros.

Despesas de Manutenção

As despesas objecto de classificação económica na rubrica com o código 02.02.19 - «Assistência técnica» não dizem respeito apenas a manutenção das SI/TI.

9. Na rubrica 02.02.19 – «Assistência Técnica» (Decreto-Lei n.º 26/2002, de 14 de Fevereiro) – deverão incluem-se as despesas realizadas referentes à assistência técnica dos bens, no âmbito de contratos realizados.

Despesa com serviços de SI/TI

As despesas objectos de classificação económicas nas rubricas com o código 02.02.14 - «Estudos, pareceres, projectos e consultadoria» e 02.02.20 - «outros trabalhos especializados» - não dizem respeito apenas a serviços de SI/TI

10. Na rubrica 02.02.14 – «Estudos, pareceres, projectos e consultadoria» (Decreto-Lei n.º 26/2002, de 14 de Fevereiro) – deverão incluem-se as despesas relativas a estudos, pareceres, projectos e consultoria, de organização, apoio à gestão e serviços de natureza técnica prestados por particulares ou outras entidades. Devem ser classificados nesta rubrica, de entre outros, os encargos com estudos de organização de projectos informáticos e estudos económico-financeiros.

11. Na rubrica 02.02.20 – «Outros trabalhos especializados» (Decreto-Lei n.º 26/2002, de 14 de Fevereiro) – deverão incluem-se as despesas relativas serviços técnicos prestados por outras empresas que o próprio organismo não pode superar pelos seus meios, tais como serviços informáticos, análises laboratoriais, trabalhos tipográficos, etc.

Material de Informática - locação financeira

Na rubrica 07.02.06 - «Material de Informática - locação financeira» incluem despesas com hardware, software, entre outros.

12. Na rubrica 07.02.06 - «Material de Informática - locação financeira», compreende as despesas com contratos de locação financeira, de acordo com a legislação em vigor, incluindo, também, a opção de compra final, sendo que a componente juros deverá ser classificada na rubrica 03.03.00 — «Juros de locação financeira».

Locação de Material de informática

A rubrica 02.02.05 - «Locação de Material de informática» incluem despesas com hardware, software, entre outros.

Respeitando o classificador económico em vigor existem outras despesas em Tecnologias de Informação que não são classificadas nas rubricas supra citadas. Dada a pouca expressividade dessas despesas não será alvo de quantificação no âmbito deste trabalho


Anexo D: Questionário

Questionário

Avaliação da Maturidade Organizacional em Gestão de Projectos na Administração Pública

1. Identificação da Entidade

Designação

Ministério/Sector

Morada

Telefone

Código Postal

Localidade

Endereço Institucional do Correio Electrónico

Endereço WWW

2. Responsável pelo preenchimento

Nome

Cargo

Telefone

Endereço de Correio Electrónico

I. CARACTERIZAÇÃO DA ENTIDADE

3. Caracterização da entidade

Natureza

Jurídica Atribuições

Regime

Financeiro

Lei

Orgânica


II. RECURSOS HUMANOS

4. Indique o número de pessoal em serviço efectivo em 31 de Dezembro de 2005, 2006, 2007, por nível de escolaridade completa.

Número

2005 2006 2007

1. Sem nível de escolaridade

2. Básico e Secundário

3. Superior

4. Total

5. Indique o número de pessoal TI em Dezembro de 2005, 2006 e 2007, por nível de escolaridade completo.

Número

2005 2006 2007

1. Sem nível de escolaridade

2. Básico e Secundário

3. Superior

4. Total

III. RECURSOS FINANCEIROS

6. Dados financeiros do organismo (relativos aos anos de 2005, 2006 e 2007):

Milhares de euros

2005 2006 2007

1. Despesa total do organismo


7. Indique o montante dos gastos em SI/TI (relativos aos anos de 2005, 2006 e 2007) em:

Milhares de euros

2005 2006 2007

1. Despesas com Comunicações (1.1+1.2+1.3+1.4+1.5+1.6)

1.1. Acessos à Internet (CE 02.02.09.A0.00)

1.2. Comunicações fixas de dados (CE 02.02.09.B0.00)

1.3. Comunicações fixas de voz (CE 02.02.09.C0.00)

1.4. Comunicações com móveis (CE 02.02.09.D0.00)

1.5. Outros serviços conexos de comunicações (CE 02.02.09.E0.00)

1.6. Outros serviços de comunicações (CE 02.02.09.F0.00)

2. Despesas com Hardware (2.1+2.2+2.3+2.4+2.5)

2.1. Equipamento de Informática (CE 07.01.07)

2.2. Equipamento administrativo (CE 07.01.09)

2.3. Equipamentos básicos (CE 07.01.10)

2.4. Material de Informática alocação financeira (CE 07.02.06)

2.5. Locação de Material informático (CE 02.02.05)

3. Despesas com Software (3.1+3.2+3.3)

3.1. Software (CE 07.01.08)

3.2. Material de informática alocação financeira (CE 07.02.06)

3.3. Locação de material informático (CE 02.02.05)

4. Despesas de Manutenção (CE 02.02.19)

5. Despesas com Consultoria (5.1+5.2)

5.1. Estudos, pareceres, projectos e consultoria (CE 02.02.14)

5.2. Outros trabalhos especializados (CE 02.02.20)

6. Outras despesas

7. Total

IV. PLANEAMENTO ESTRATÉGICO DE TI E GESTÃO DE PROJECTOS DE SI/TI

Os quadros que se seguem caracterizam os objectivos de controlo para avaliação da situação relativamente aos processos de Planeamento Estratégico de TI e Gestão de Projectos extraídos do Framework CobiT. Assinale com X a coluna mais ajustada à situação real da sua organização. Os níveis de situação foram retirados do modelo de maturidade CMMI (Capability Maturity Model Integrated) em anexo.


8. Processo: PO1 – Definir um Plano Estratégico de TI

Nível Real da Entidade Comentário

Inex

iste

nte

Inic

ial

/ A

d

Ho

c

Rep

etí

vel,

ma s

intu

itiv

o

Pro

cess

os

Defi

nid

os

Pro

cess

os

Geri

do

s e

Med

ido

s

Pro

cess

os

Op

tim

izad

os

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 e 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.

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.


9. Processo: PO10 – Gestão de Projectos

Situação real verificada na entidade Comentário

Inex

iste

nte

Inic

ial

/ A

d

Ho

c

Rep

etí

vel,

ma s

intu

itiv

o

Pro

cess

os

Defi

nid

os

Pro

cess

os

Geri

do

s e

Med

ido

s

Pro

cess

os

Op

tim

izad

os

Objectivo de Controlo: 10.1. 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, e resolver os pedidos de recursos e conflitos de recursos.

Objectivo de Controlo: 10.2. 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: 10.3. 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 e 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: 10.4. 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: 10.5. 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: 10.6. 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.

Objectivo de Controlo: 10.7. 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 e 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: 10.8. 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 e 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: 10.9. 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 e registados centralmente.

Objectivo de Controlo: 10.10. Plano de Qualidade do Projecto

Preparar um plano de qualidade que descreva o sistema de qualidade do projecto e como ela será implementada. O plano deverá ser formalmente analisado e acordado por todas as partes envolvidas e, em seguida, incorporada no plano do projecto.

Objectivo de Controlo: 10.11. 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: 10.12. 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: 10.13. 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 e acompanhar acções correctivas, quando necessário, em consonância com a framework de gestão de programa e de projecto.

Objectivo de Controlo: 10.14. 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 e os benefícios do programa, bem como identificar e documentar as lições apreendidas para uso em futuros projectos e programas.


Anexo

Modelo CMMI (“Capability Maturity Model Integration”)

Este anexo descreve o Modelo de Maturidade de Capacidades a utilizar na pontuação do nível de maturidade atingido na realização de cada objectivo da norma adoptada na avaliação de controlo interno:

0. Estádio “Inexistência”

(a) A organização não reconhece a existência do problema, não existindo, portanto, qualquer comunicação relacionada com o mesmo.

(b) Inexistência de qualquer política relacionada com o problema.

(c) Total inexistência de qualquer procedimento reconhecível conexo com o problema.

(d) Inexistência de qualquer medição relacionada com o problema.

1. Estádio “Inicial/Ad hoc”

(a) Existem indícios de que a organização reconhece a existência do problema e a necessidade de o resolver, mas falta comunicação coerente sobre o assunto.

(b) Existe um esboço de política, mas esta não se encontra bem documentada, publicada ou posta em prática.

(c) São aplicadas abordagens ad hoc de forma individual ou casuística. O problema não é totalmente coberto.

(d) Controlo apenas de tipo reactivo, em caso de incidente de que tenham resultado perdas para a organização.

2. Estádio “Repetível, mas intuitivo”

(a) A existência do problema é adequadamente reconhecida aos níveis apropriados da organização.

(b) Existe uma política clara.

(c) Encontram-se formalmente estabelecidos procedimentos conexos que abrangem todo o problema, com supervisão e envolvimento activos ao nível da gestão, mas os procedimentos em causa não são seguidos pela organização no seu todo. Não existe formação e a comunicação de normas e responsabilidades é feita numa base individual.

(d) Os responsáveis pela gestão identificaram determinadas medições básicas e determinados métodos e técnicas de avaliação, que se encontram em desenvolvimento.


3. Estádio “Procedimento definido”

(a) A necessidade de tratar o problema é entendida e aceite em toda a organização.

(b) Existe uma política forte e clara, alinhada com algumas políticas conexas. É dada alguma atenção à gestão de riscos.

(c) Os procedimentos encontram-se normalizados, documentados e amplamente postos em prática em toda a organização. Os responsáveis pela gestão comunicaram procedimentos normalizados e existe formação informal. Os procedimentos não são sofisticados, mas são mensuráveis e constituem a formalização de práticas estabelecidas.

(d) A aplicação de indicadores de desempenho a actividades conexas está a ser registada e acompanhada, conduzindo a aperfeiçoamentos. O andamento da maioria dos procedimentos conexos é seguido em relação a algum tipo de parâmetro mensurável (linha de base), mas é improvável que os desvios venham a ser detectados ao nível da gestão, apesar de serem corrigidos por iniciativa individual. Só ocasionalmente é efectuada uma análise de causas profundas.

4. Estádio “Gerido e mensurável”

(a) Existe um entendimento completo do problema a todos os níveis adequados e foram requeridas medidas.

(b) Existe uma política forte e clara, posta em prática em articulação com outras políticas (conexas). É tida em conta a gestão de riscos.

(c) Existe um entendimento claro de quem é o cliente, com definição das responsabilidades. Os procedimentos estão bem definidos, integrados e são bem-postos em prática em toda a organização. A responsabilidade por cada procedimento encontra-se definida e é apoiada por formação formal. Todas as partes envolvidas nos procedimentos conexos estão conscientes dos riscos e das oportunidades potencialmente criadas.

(d) O aperfeiçoamento dos procedimentos conexos tem por base, sobretudo, considerações quantitativas, sendo possível seguir e medir a observância dos procedimentos e os parâmetros que lhes estão associados. Os responsáveis pela gestão definiram tolerâncias operacionais dos procedimentos conexos. Quando os procedimentos parecem não funcionar eficazmente, ou com eficiência, são muitas vezes (mas nem sempre) tomadas medidas. Os procedimentos conexos são, por vezes, aperfeiçoados e põem-se em prática melhores práticas internas. A análise de causas profundas está a ser normalizada. A problemática do aperfeiçoamento contínuo está a começar a ser abordada.

5. Estádio “Optimizado”

(a) Existe um entendimento avançado e progressista do problema e das soluções.

(b) Existe uma política forte e clara, posta em prática em articulação total com outras políticas (conexas) e com total ponderação da gestão de riscos.


(c) Com base nos resultados do aperfeiçoamento contínuo e em modelos de maturidade estabelecidos em conjunto com outras organizações, os procedimentos conexos foram afinados até ao nível da aplicação de melhores práticas externas. Os riscos e consequências dos procedimentos conexos foram definidos, equilibrados e comunicados em toda a organização. A formação e a comunicação estão actualizadas. A aplicação da política adoptada conduziu a uma organização e a pessoas e procedimentos rapidamente adaptáveis e capazes de absorver plenamente qualquer modificação ocorrida na estrutura de riscos.

(d) O controlo, a auto-avaliação e a comunicação sobre o problema estão generalizados na organização (aos níveis apropriados) e o recurso a procedimentos e tecnologia de apoio às medições, análise, comunicação e formação encontra-se optimizado. São analisadas as causas profundas de todos os problemas e desvios e convenientemente identificadas e postas em prática medidas eficientes. Recorre-se a peritos e normas externos, a título de orientação.


Anexo E: Respostas ao Questionário

Apresenta-se de seguida a codificação efectuada às variáveis do questionário:

- Min – Código do Ministério;

- Serviço – Código do serviço;

Recursos Humanos

- RH-G-S-2005 – Número de pessoal em serviço em 31 Dezembro de 2005, sem nível de escolaridade;

- RH-G-SBS-2005 - Número de pessoal em serviço em 31 Dezembro de 2005, básico e secundário;

- RH-G-SS-2006 - Número de pessoal em serviço em 31 Dezembro de 2005, superior;

- Total2005 – Número de pessoal em serviço em 31 de Dezembro de 2005;









- Média2005-2007- Média do número de pessoal no triénio 2005 a 2007;

Recursos Humanos TI

- RH-TI-SBS-2005 - Número de pessoal de TI em serviço em 31 Dezembro de 2005, básico e

secundário;

- RH-TI-SS-2006 - Número de pessoal de TI em serviço em 31 Dezembro de 2005, superior;

- TotalTI2005 – Número de pessoal de TI em serviço em 31 de Dezembro de 2005;


secundário;




secundário;



- MédiaTI2005-2007- Média do número de pessoal de TI no triénio 2005 a 2007;

- % - Média de recursos humanos de TI por média de recursos humanos globais, 2005 a 2007;


Despesa em Total

- DTO-2005 – Despesa total do organismo, 2005;

- DTO-2006 - Despesa total do organismo, 2006;

- DTO-2007 - Despesa total do organismo, 2007;

- Média-Desp2005-2007 – Média da despesa total do organismo, 2005 a 2007;

Despesa em TI

- DTI-2005 – Despesa de TI, 2005;

- DTI-2006 - Despesa TI, 2006

- DTI-2007 – Despesa TI, 2007

- Média-Desp-TI-2005-2007 – Média da despesa de TI, 2005 a 2007;

- %DespTI – Média da despesa de TI por média da despesa total dos organismos, 2005 a 2007;

Planeamento Estratégico de TI

- PO1-1.1 – Gerir o valor de TI;

- PO1.1.2 – Alinhamento das TI com o negócio;

- PO1.1.3 – Avaliação de desempenho e capacidade actual;

- PO1.1.4 – Plano estratégico de TI;

- PO1.1.5 – Planos tácticos TI;

- PO1.1.6 – Gerir o portfolio de TI;

Gestão de Projectos

- PO10-1.1 – Framework de gestão de programa;

- PO10.1.2 – Framework de gestão de projectos;

- PO10.1.3 – Abordagem de gestão de projectos;

- PO10.1.4 – Compromisso de stakeholder;

- PO10.1.5 – Declaração de âmbito do projecto;

- PO10.1.6 – Fase inicial do projecto;

- PO10.1.7 – Planeamento integrado do projecto;

- PO10.1.8 – Recursos do projecto;

- PO10.1.9 – Gestão do risco do projecto;

- PO10.1.10 – Plano de qualidade do projecto;

- PO10.1.11 – Controlo das alterações do projecto;

- PO10.1.12 – Planeamento de métodos de segurança;

- PO10.1.13 – Medir, reportar e monitorizar o desempenho do projecto;

- PO10.1.14 – Encerramento do projecto.


E.1 Recursos Humanos – 2005 A 2007

Min Serviço

RH

-G-S

-2005

RH

-G-S

BS

-2005

RH

-G-S

S-2

005

To

tal

2005

RH

-G-S

-2006

RH

-G-S

BS

-2006

RH

-G-S

S-2

006

To

tal

2006

RH

-G-S

-2007

RH

-G-S

BS

-2007

RH

-G-S

S-2

007

To

tal

2007

Méd

ia 2

005-2

007

MA MAS1 0 101 59 160 0 80 50 130 0 87 64 151 147

MB MBS1 0 976 439 1.415 0 968 443 1.411 0 1.004 458 1.462 1.429 MBS2 0 22.004 604 22.608 0 21.896 614 22.510 0 21.703 510 22.213 22.444 MBS3 11 24.594 833 25.438 10 25.064 867 25.941 10 24.157 905 25.072 25.484

MC MCS1 0 502 725 1.227 0 462 696 1.158 0 434 723 1.157 1.181 MCS2 NE NE NE NE NE NE NE NE NE

MD MDS1 NE NE NE NE NE NE NE NE NE MDS2 0 141 138 279 0 136 142 278 0 132 146 278 278 MDS3 0 112 139 251 0 104 141 245 0 94 129 223 240 MDS4 0 218 62 280 1 203 69 273 0 193 71 264 272

ME MES1 0 0 0 0 0 0 0 0 0 140 117 257 86 MES2 0 220 54 274 0 227 54 281 0 217 56 273 276 MES3 1.057 10.620 1250 12.927 1.720 9.826 1.260 12.806 1.780 9.704 1.252 12.736 12.823

MF MFS1 0 68 68 136 0 55 52 107 0 57 51 108 117 MFS2 26 9.560 412 9.998 24 9.200 358 9.582 18 8.948 393 9.359 9.646 MFS3 0 360 298 658 0 347 340 687 0 386 326 712 686 MFS4 0 63 63 126 0 60 69 129 0 58 68 126 127

MG MGS1 0 92 119 211 0 91 107 198 0 89 151 240 216 MGS2 0 178 179 357 0 171 168 339 0 150 195 345 347 MGS3 56 187 97 340 52 173 88 313 44 169 86 299 317 MGS4 2 280 272 554 2 253 260 515 2 240 261 503 524

MH MHS1 0 107 263 370 0 110 270 380 0 106 261 367 372 MHS2 0 136 76 212 0 113 77 190 0 108 82 190 197

MI MIS1 0 699 504 1.203 0 481 479 960 0 462 472 934 1.032 MIS2 108 1.436 329 1.873 81 901 349 1.331 64 860 322 1.246 1.483 MIS3 2 170 278 450 1 157 105 263 0 97 77 174 296

MJ MJS1 59 135 215 409 49 126 228 403 48 128 225 401 404 MJS2 28 92 45 165 25 79 42 146 22 69 48 139 150

MK MKS1 2 2.166 1.662 3.830 2 2.067 1.686 3.755 2 1978 1703 3.683 3.756 MKS2 15 55 135 205 18 78 113 209 15 51 143 209 208

ML MLS1 NR NR NR NR NR NR NR NR NR MLS2 0 443 265 708 0 485 286 771 - 634 408 1.042 840 MLS3 3 615 1.175 1.793 3 602 1.166 1.771 3 637 1.228 1.868 1.811

MM MMS1 1 203 244 448 1 169 268 438 1 107 203 311 399 MMS2 0 270 513 783 0 234 320 554 - 195 232 427 588 MMS3 0 37 42 79 0 38 33 71 - 48 79 127 92

MN MNS1 0 267 116 383 - 244 114 358 - 235 114 349 363 MNS2 1 454 1.129 1.584 1 463 1.148 1.612 1 437 1.126 1.564 1.587

MO MOS1 0 137 61 198 0 133 57 190 - 130 59 189 192 MOS2 0 24 41 65 0 19 38 57 - 25 36 61 61

Legenda: (NR) Entidade que não respondeu ao questionário; (NE) Entidade em que à área das Tecnologias de Informação são desempenhadas por outra entidade.

Tabela 54 – Recursos Humanos – 2005 a 2007.

Fonte: Autor.


E.2 Recursos Humanos de TI – 2005 A 2007

Min Serviço

RH

-TI-

SB

S-2

005

RH

-TI-

S-2

005

To

tal

–R

H-T

I 2005

RH

-TI-

SB

S-2

006

RH

-TI-

S-2

006

To

tal

TI-

2006

RH

-TI-

SB

S-2

007

RH

-TI-

S-2

007

To

tal

TI

2007

Méd

ia 2

005-2

007

%

MA MAS1 20 5 25 18 4 22 19 7 26 24 16,55%

MB

MBS1 29 15 44 28 12 40 23 14 37 40 2,82% MBS2 154 18 172 159 19 178 155 19 174 175 0,78% MBS3 27 18 45 27 18 45 28 14 42 44 0,17%

MC MCS1 24 4 28 25 4 29 23 4 27 28 2,37% MCS2 NE NE NE NE NE NE

MD

MDS1 NE NE NE NE NE NE MDS2 80 127 207 78 131 209 76 127 203 206 74,13% MDS3 59 74 133 56 76 132 55 86 141 135 56,47% MDS4 9 4 13 6 5 11 9 5 14 13 4,65%

ME

MES1 0 0 0 0 0 - 40 60 100 33 38,91% MES2 214 54 268 220 54 274 211 56 267 270 97,71% MES3 77 91 168 70 58 128 84 59 143 146 1,14%

MF

MFS1 0 0 0 0 0 0 1 2 3 1 0,85% MFS2 94 8 102 94 8 102 94 8 102 102 1,06% MFS3 0 3 3 0 3 3 0 3 3 3 0,44% MFS4 21 45 66 20 49 69 18 50 68 68 53,28%

MG

MGS1 10 11 21 11 9 20 11 10 21 21 9,55% MGS2 14 5 19 14 5 19 13 8 21 20 5,67% MGS3 6 3 9 6 3 9 5 3 8 9 2,73% MGS4 7 9 16 7 9 16 7 9 16 16 3,05%

MH MHS1 7 0 7 7 0 7 6 1 7 7 1,88% MHS2 17 14 31 18 12 30 18 12 30 30 15,37%

MI

MIS1 42 18 60 41 18 59 41 18 59 59 5,75% MIS2 10 9 19 10 9 19 10 9 19 19 1,28% MIS3 9 5 14 9 5 14 8 4 12 13 4,51%

MJ MJS1 13 19 32 12 19 31 11 20 31 31 7,75% MJS2 4 1 5 1 1 2 1 3 4 4 2,44%

MK MKS1 39 19 58 38 16 54 38 15 53 55 1,46% MKS2 50 109 159 46 115 161 44 117 161 160 77,21%

ML

MLS1 NR NR NR NR NR NR MLS2 11 2 13 11 2 13 11 2 13 13 1,55% MLS3 14 7 21 5 8 23 15 9 24 23 1,25%

MM

MMS1 3 3 6 3 3 6 3 3 6 6 1,50% MMS2 2 7 9 2 7 9 2 6 8 9 1,47% MMS3 4 1 5 4 2 6 5 2 7 6 6,50%

MN MNS1 10 7 17 11 8 19 13 8 21 19 5,23% MNS2 26 17 43 24 26 50 23 25 48 47 2,96%

MO MOS1 3 - 3 3 - 3 3 1 4 3 1,73% MOS2 - - 0 - - - 0 0 0 0 0,00%


Tabela 55 – Recursos Humanos de TI – 2005 a 2007.

Fonte: Autor.


E.3 Despesa Global – 2005 a 2007

Min Serviço

DT

O-2

005

DT

O-2

006

DT

O-2

007

Méd

ia_

Desp

-

20005-2

007

MA MAS1 14.390 12.766 13.159 13.438

MB MBS1 54.438 65.040 78.981 66.153

MBS2 590.255 567.983 581.727 579.989

MBS3 721.748 728.205 760.807 736.920

MC MCS1 175.926 174.378 172.292 174.199

MCS2 NE NE NE

MD MDS1 NE NE NE

MDS2 54.291 62.001 62.311 59.534

MDS3 14.713 11.694 12.489 12.965

MDS4 870.949 945.932 926.564 914.482

ME MES1 4.588,6 6.568,9 10.814,2 7.324

MES2 354.823 329.777 319.188 334.596

MES3 10.097 25.250 69.415 34.921

MF MFS1 14.812 17.914 15.556 16.094

MFS2 217.610 210.006 257.300 228.305

MFS3 33.408 32.422 249.977 105.269

MFS4 14.812 17.914 15.556 16.094

MG MGS1 17.961 18.674 17.180 17.938 MGS2 264.781 180.984 247.769 231.178

MGS3 8.626 9.270 10.349 9.415

MGS4 21.282 19.448 26.815 22.515

MH MHS1 20.337 24.576 27.059 23.990

MHS2 16.661 9.834 8.660 11.718

MI MIS1 1.894.377 1.629.598 1.602.099 1.708.691

MIS2 13.305 15.944 15.782 15.010

MIS3 15.322 12.340 11.386 13.016

MJ MJS1 64.955 63.150 50.783 59.629

MJS2 7.722 6.007 8.398 7.376

MK MKS1 1.042.609 1.000.815 841.259 961.561

MKS2 32.803 32.676 34.717 33.399

ML MLS1 NR NR NR

MLS2 39.754 45.737 55.016 46.836

MLS3 62.170 68.109 66.485 65.588

MM MMS1 161.913 174.741 221.108 185.921

MMS2 228.358 242.747 269.385 246.830

MMS3 4.573 2.511 4.520 3.868

MN MNS1 15.592 16.968 19.776 17.445

MNS2 99.286 105.944 100.258 101.829

MO MOS1 7.517 4.617 7.054 6.396

MOS2 9.083 8.508 8.091 8.561


Tabela 56 – Despesa Global – 2005 a 2007.

Fonte: Autor.


E.4 Despesa em TI – 2005 a 2007

Min Serviço DTI-2005 DTI-2006 DTI-2007 Média-Desp-TI-2005-2007 %Desp-TI

MA MAS1 4.208 3.537 4.190 3.978 29,60%

MB

MBS1 8.274 11.786 14.987 11.683 17,66%

MBS2 13.368 11.116 10.606 11.697 2,02%

MBS3 9.060 11.943 13.519 11.507 1,56%

MC MCS1 7.134 7.415 5.317 6.622 3,80%

MCS2 NE NE NE

MD

MDS1 NE NE NE

MDS2 42.784 50.434 50.850 48.023 80,66%

MDS3 7.008 3.546 3.331 4.629 35,70%

MDS4 1.802 1.422 1.814 1.679 0,18%

ME

MES1 153,50 601,96 1.795,12 850 11,61%

MES2 5.369 3.474 3.743 4.195 1,25%

MES3 10.130 2.300 768 4.399 12,60%

MF

MFS1 10.000 13.375 9.461 10.945 68,01%

MFS2 8.476 5.665 14.920 9.687 4,24% MFS3 3.257 5.307 16.028 8.197 7,79%

MFS4 10.000 13.375 9.461 10.945 68,01%

MG

MGS1 15.676 12.948 13.949 14.191 79,11%

MGS2 4.849 4.723 3.561 4.378 1,89%

MGS3 273 850 1.330 818 8,68%

MGS4 748 630 923 767 3,41%

MH MHS1 879 973 1.018 957 3,99%

MHS2 2.225 1.982 1.864 2.024 17,27%

MI

MIS1 5.611 6.895 6.613 6.373 0,37%

MIS2 959 1.584 845 1.129 7,52%

MIS3 2.025 1.979 1.830 1.945 14,94%

MJ MJS1 4.231 2.830 4.742 3.934 6,60%

MJS2 592 922 986 833 11,30%

MK MKS1 25.063 23.192 22.720 23.658 2,46%

MKS2 21.218 20.754 22.592 21.521 64,44%

ML

MLS1 NR NR NR

MLS2 9.950 9.143 9.556 9.550 20,39%

MLS3 1.468 2.690 2.448 2.202 3,36%

MM

MMS1 1.047 1.979 6.768 3.265 1,76%

MMS2 8.641 14.149 830 7.874 3,19%

MMS3 4.038 2.195 4.231 3.488 90,18%

MN MNS1 3.571 5.154 4.691 4.472 25,64%

MNS2 991 1.269 1.066 1.109 1,09%

MO MOS1 1.207 1.335 1.836 1.459 22,82%

MOS2 595 415 1.181 731 8,53% Legenda: (NR) Entidade que não respondeu ao questionário; (NE) Entidade em que à área das Tecnologias de Informação são desempenhadas por outra entidade.

Tabela 57 – Despesa em TI – 2005 a 2007.

Fonte: Autor.


E.5 Planeamento Estratégico de TI

Min. Serviço PO1-1.1 PO1-1.2 PO1-1.3 PO1-1.4 PO1-1.5 PO1-1.6 PO1-Media

MA MAS1 1 1 1 0 0 0 0,5

MB MBS1 2 3 3 4 3 2 2,8

MBS2 0 1 1 2 2 2 1,3

MBS3 3 3 2 2 2 2 2,3

MC MCS1 2 1 0 1 1 1 1,0

MCS2 NE NE NE NE NE NE

MD MDS1 NE NE NE NE NE NE

MDS2 2 2 3 1 3 3 2,3

MDS3 1 2 2 2 2 0 1,5

MDS4 2 2 2 1 1 1 1,5

ME MES1 1 1 1 1 1 1 1,0

MES2 1 1 1 2 2 1 1,3

MES3 3 3 2 3 3 2 2,7

MF MFS1 3 3 3 3 3 3 3,0

MFS2 1 1 2 2 2 2 1,7

MFS3 2 2 2 1 1 2 1,7

MFS4 2 3 4 3 3 2 2,8

MG MGS1 1 1 0 1 1 1 0,8

MGS2 2 1 1 1 2 2 1,5

MGS3 1 1 1 1 1 1 1,0

MGS4 1 1 1 4 4 3 2,3

MH MHS1 2 3 2 3 3 2 2,5

MHS2 3 3 3 3 3 1 2,7

MI MIS1 2 2 1 3 3 3 2,3

MIS2 2 2 2 1 1 2 1,7

MIS3 1 1 1 0 0 1 0,7

MJ MJS1 4 4 3 4 4 2 3,5

MJS2 3 2 2 2 3 2 2,3

MK MKS1 3 3 3 3 3 3 3,0

MKS2 4 4 4 4 4 4 4,0

ML MLS1 NR NR NR NR NR NR

MLS2 2 2 1 2 1 2 1,7

MLS3 3 2 4 1 1 2 2,2

MM MMS1 1 1 1 0 0 1 0,7

MMS2 2 3 2 2 1 1 1,8

MMS3 3 3 3 2 2 3 2,7

MN MNS1 0 2 1 1 1 1 1,0

MNS2 3 3 3 3 3 4 2,8

MO MOS1 1 0 1 1 1 1 0,8

MOS2 2 3 2 3 3 2 2,5 Legenda: (NR) Entidade que não respondeu ao questionário; (NE) Entidade em que à área das Tecnologias de Informação são desempenhadas por outra entidade.

Tabela 58 – Nível de Maturidade dos Objectivos de Controlo do Processo PO1 (Planeamento Estratégico de TI).

Fonte: Autor.


E.6 Gestão de Projectos

Min Serviço

PO

10-1

.1

PO

10-1

.2

PO

10-1

.3

PO

10-1

.4

PO

10-1

.5

PO

10-1

.6

PO

10-1

.7

PO

10-1

.8

PO

10-1

.9

PO

10-1

.10

PO

10-1

.11

PO

10-1

.12

PO

10-1

.13

PO

10-1

.14

PO

10-

Med

ia

MA MAS1 1 0 1 0 2 0 0 1 1 0 0 1 1 1 0,6

MB

MBS1 2 0 1 1 2 1 1 2 1 1 2 1 2 2 1,4

MBS2 0 0 1 0 1 1 1 1 0 1 1 1 0 1 0,6

MBS3 1 1 1 1 2 2 2 2 2 2 2 2 2 2 1,7

MC MCS1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1,0

MCS2 NE NE NE NE NE NE NE NE NE NE NE NE NE NE

MD

MDS1 NE NE NE NE NE NE NE NE NE NE NE NE NE NE

MDS2 3 3 3 2 3 3 3 2 3 3 3 3 3 3 2,9

MDS3 1 2 3 2 2 2 2 2 2 2 2 2 2 2 2,0

MDS4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1,0

ME

MES1 3 3 3 1 1 1 3 3 1 3 3 1 1 1 2,0

MES2 2 2 2 2 2 2 2 2 1 1 1 2 1 1 1,6

MES3 4 3 3 3 3 3 4 3 2 2 2 3 3 3 2,9

MF

MFS1 2 2 2 2 3 2 2 2 2 0 2 2 2 2 1,9

MFS2 2 1 1 2 2 2 1 1 1 0 1 1 2 1 1,3

MFS3 1 1 1 1 1 1 1 2 1 1 2 1 2 2 1,3

MFS4 2 2 3 3 3 3 3 3 3 3 3 3 3 3 2,9

MG

MGS1 0 1 1 1 1 1 1 1 1 1 1 1 1 1 0,9

MGS2 1 1 1 3 2 3 1 2 2 1 3 3 1 3 1,9

MGS3 1 0 1 1 1 1 0 1 1 0 0 0 0 0 0,5

MGS4 1 1 2 2 2 1 2 2 4 2 3 2 2 2 2,0

MH MHS1 2 2 3 3 3 3 2 3 2 1 2 1 2 2 2,2

MHS2 0 1 2 1 3 3 3 3 0 0 0 0 0 0 1,1

MI

MIS1 1 2 1 1 3 2 2 3 2 0 2 3 2 1 1,8

MIS2 0 0 0 0 2 3 3 3 1 0 0 1 0 0 0,9

MIS3 1 0 0 2 3 2 2 1 2 0 1 1 2 3 1,4

MJ MJS1 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4,0

MJS2 1 1 1 1 1 2 1 2 2 1 1 2 1 1 1,3

MK MKS1 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3,0

MKS2 1 1 1 1 1 2 1 2 2 1 1 2 1 1 1,3

ML

MLS1 NR NR NR NR NR NR NR NR NR NR NR NR NR NR

MLS2 4 2 4 4 1 4 4 4 3 1 3 3 2 4 3,1

MLS3 1 1 3 3 3 3 3 3 3 3 3 3 3 3 2,7

MM

MMS1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 0,9

MMS2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1,0

MMS3 3 2 3 4 2 3 3 3 3 3 3 3 3 4 3,0

MN MNS1 1 0 1 1 1 2 1 2 1 1 1 1 0 1 1,0

MNS2 3 3 3 4 2 3 3 2 2 2 4 5 2 3 2,9

MO MOS1 2 3 2 3 3 3 2 3 1 0 1 2 2 2 2,1

MOS2 2 1 2 2 2 2 2 2 1 1 1 1 1 1 1,5 Legenda: (NR) Entidade que não respondeu ao questionário; (NE) Entidade em que à área das Tecnologias de Informação são desempenhadas por outra entidade.

Tabela 59 – Nível de Maturidade dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos).

Fonte: Autor.


E.7 Correlação entre os Objectivos de Controlo do Processo PO1 (Planeamento

Estratégico de TI)

PO1-Media PO1-1.1 PO1-1.2 PO1-1.3 PO1-1.4 PO1-1.5 PO1-1.6

PO1-Media Pearson Correlation

1,000 ,823** ,875** ,810** ,840** ,867** ,765**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,000

N 37,000 37 37 37 37 37 37

PO1-1.1 Pearson Correlation

,823** 1,000 ,783** ,702** ,504** ,554** ,571**

Sig. (2-tailed) ,000 ,000 ,000 ,001 ,000 ,000

N 37 37,000 37 37 37 37 37


,875** ,783** 1,000 ,762** ,678** ,626** ,502**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,002

N 37 37 37,000 37 37 37 37


,810** ,702** ,762** 1,000 ,494** ,543** ,530**

Sig. (2-tailed) ,000 ,000 ,000 ,002 ,001 ,001

N 37 37 37 37,000 37 37 37


,840** ,504** ,678** ,494** 1,000 ,897** ,574**

Sig. (2-tailed) ,000 ,001 ,000 ,002 ,000 ,000

N 37 37 37 37 37,000 37 37


,867** ,554** ,626** ,543** ,897** 1,000 ,689**

Sig. (2-tailed) ,000 ,000 ,000 ,001 ,000 ,000

N 37 37 37 37 37 37,000 37


,765** ,571** ,502** ,530** ,574** ,689** 1,000

Sig. (2-tailed) ,000 ,000 ,002 ,001 ,000 ,000

N 37 37 37 37 37 37 37,000

**. Correlation is significant at the 0.01 level (2-tailed).

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).

Fonte: Autor.




1,000 ,761** ,892** ,853** ,811** ,846** ,626**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,001

N 25,000 25 25 25 25 25 25


,761** 1,000 ,772** ,546** ,426* ,477* ,448*

Sig. (2-tailed) ,000 ,000 ,005 ,034 ,016 ,025

N 25 25,000 25 25 25 25 25


,892** ,772** 1,000 ,754** ,695** ,603** ,422*

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,001 ,036

N 25 25 25,000 25 25 25 25


,853** ,546** ,754** 1,000 ,584** ,672** ,505*

Sig. (2-tailed) ,000 ,005 ,000 ,002 ,000 ,010

N 25 25 25 25,000 25 25 25


,811** ,426* ,695** ,584** 1,000 ,826** ,294

Sig. (2-tailed) ,000 ,034 ,000 ,002 ,000 ,154

N 25 25 25 25 25,000 25 25


,846** ,477* ,603** ,672** ,826** 1,000 ,473*

Sig. (2-tailed) ,000 ,016 ,001 ,000 ,000 ,017

N 25 25 25 25 25 25,000 25


,626** ,448* ,422* ,505* ,294 ,473* 1,000

Sig. (2-tailed) ,001 ,025 ,036 ,010 ,154 ,017

N 25 25 25 25 25 25 25,000

**. Correlation is significant at the 0.01 level (2-tailed). *. Correlation is significant at the 0.05 level (2-tailed).

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).

Fonte: Autor.




1,000 ,858** ,842** ,741** ,839** ,850** ,832**

Sig. (2-tailed) ,000 ,001 ,006 ,001 ,000 ,001

N 12,000 12 12 12 12 12 12


,858** 1,000 ,772** ,851** ,500 ,544 ,596*

Sig. (2-tailed) ,000 ,003 ,000 ,098 ,067 ,041

N 12 12,000 12 12 12 12 12


,842** ,772** 1,000 ,742** ,603* ,581* ,495

Sig. (2-tailed) ,001 ,003 ,006 ,038 ,048 ,102

N 12 12 12,000 12 12 12 12


,741** ,851** ,742** 1,000 ,312 ,299 ,488

Sig. (2-tailed) ,006 ,000 ,006 ,324 ,344 ,108

N 12 12 12 12,000 12 12 12


,839** ,500 ,603* ,312 1,000 ,959** ,758**

Sig. (2-tailed) ,001 ,098 ,038 ,324 ,000 ,004

N 12 12 12 12 12,000 12 12


,850** ,544 ,581* ,299 ,959** 1,000 ,818**

Sig. (2-tailed) ,000 ,067 ,048 ,344 ,000 ,001

N 12 12 12 12 12 12,000 12


,832** ,596* ,495 ,488 ,758** ,818** 1,000

Sig. (2-tailed) ,001 ,041 ,102 ,108 ,004 ,001

N 12 12 12 12 12 12 12,000


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).

Fonte: Autor.


E.8 Correlação entre os Objectivos de Controlo do Processo PO10 (Gestão de

Projectos)

PO10-1.1 PO10-1.2 PO10-1.3 PO10-1.4 PO10-1.5 PO10-1.6 PO10-1.7 PO10-1.8 PO10-1.9 PO10-1.10 PO10-1.11 PO10-1.12 PO10-1.13 PO10-1.14 PO10-Media


1,000 ,771** ,773** ,736** ,366* ,536** ,653** ,559** ,534** ,546** ,661** ,618** ,684** ,694** ,813**

Sig. (2-tailed) ,000 ,000 ,000 ,026 ,001 ,000 ,000 ,001 ,000 ,000 ,000 ,000 ,000 ,000

N 37,000 37 37 37 37 37 37 37 37 37 37 37 37 37 37


,771** 1,000 ,798** ,673** ,489** ,574** ,696** ,611** ,507** ,596** ,673** ,688** ,671** ,555** ,822**

Sig. (2-tailed) ,000 ,000 ,000 ,002 ,000 ,000 ,000 ,001 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37,000 37 37 37 37 37 37 37 37 37 37 37 37 37


,773** ,798** 1,000 ,769** ,440** ,619** ,757** ,697** ,602** ,705** ,724** ,620** ,648** ,657** ,866**

Sig. (2-tailed) ,000 ,000 ,000 ,006 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37,000 37 37 37 37 37 37 37 37 37 37 37 37


,736** ,673** ,769** 1,000 ,545** ,768** ,658** ,600** ,682** ,507** ,734** ,744** ,720** ,837** ,879**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,001 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37,000 37 37 37 37 37 37 37 37 37 37 37


,366* ,489** ,440** ,545** 1,000 ,612** ,581** ,545** ,476** ,253 ,369* ,451** ,641** ,474** ,619**

Sig. (2-tailed) ,026 ,002 ,006 ,000 ,000 ,000 ,000 ,003 ,131 ,025 ,005 ,000 ,003 ,000

N 37 37 37 37 37,000 37 37 37 37 37 37 37 37 37 37


,536** ,574** ,619** ,768** ,612** 1,000 ,790** ,784** ,537** ,362* ,500** ,644** ,508** ,617** ,771**

Sig. (2-tailed) ,001 ,000 ,000 ,000 ,000 ,000 ,000 ,001 ,028 ,002 ,000 ,001 ,000 ,000

N 37 37 37 37 37 37,000 37 37 37 37 37 37 37 37 37


,653** ,696** ,757** ,658** ,581** ,790** 1,000 ,821** ,558** ,575** ,612** ,614** ,593** ,609** ,829**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37,000 37 37 37 37 37 37 37 37


,559** ,611** ,697** ,600** ,545** ,784** ,821** 1,000 ,517** ,441** ,539** ,527** ,493** ,499** ,751**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,001 ,006 ,001 ,001 ,002 ,002 ,000

N 37 37 37 37 37 37 37 37,000 37 37 37 37 37 37 37


,534** ,507** ,602** ,682** ,476** ,537** ,558** ,517** 1,000 ,661** ,769** ,737** ,784** ,775** ,809**

Sig. (2-tailed) ,001 ,001 ,000 ,000 ,003 ,001 ,000 ,001 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37,000 37 37 37 37 37 37


,546** ,596** ,705** ,507** ,253 ,362* ,575** ,441** ,661** 1,000 ,783** ,604** ,653** ,628** ,740**

Sig. (2-tailed) ,000 ,000 ,000 ,001 ,131 ,028 ,000 ,006 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37 37,000 37 37 37 37 37


,661** ,673** ,724** ,734** ,369* ,500** ,612** ,539** ,769** ,783** 1,000 ,813** ,754** ,824** ,868**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,025 ,002 ,000 ,001 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37 37 37,000 37 37 37 37


,618** ,688** ,620** ,744** ,451** ,644** ,614** ,527** ,737** ,604** ,813** 1,000 ,707** ,769** ,842**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,005 ,000 ,000 ,001 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37 37 37 37,000 37 37 37


,684** ,671** ,648** ,720** ,641** ,508** ,593** ,493** ,784** ,653** ,754** ,707** 1,000 ,839** ,859**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,001 ,000 ,002 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37 37 37 37 37,000 37 37


,694** ,555** ,657** ,837** ,474** ,617** ,609** ,499** ,775** ,628** ,824** ,769** ,839** 1,000 ,867**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,003 ,000 ,000 ,002 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37 37 37 37 37 37,000 37


,813** ,822** ,866** ,879** ,619** ,771** ,829** ,751** ,809** ,740** ,868** ,842** ,859** ,867** 1,000

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000

N 37 37 37 37 37 37 37 37 37 37 37 37 37 37 37,000

*. Correlation is significant at the 0.05 level (2-tailed). **. Correlation is significant at the 0.01 level (2-tailed).

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).

Fonte: Autor.



PO10-1.1 Pearson Correlation 1,000 ,711** ,757** ,760** ,260 ,484* ,606** ,552** ,614** ,511** ,721** ,695** ,684** ,690** ,837**

Sig. (2-tailed) ,000 ,000 ,000 ,209 ,014 ,001 ,004 ,001 ,009 ,000 ,000 ,000 ,000 ,000

N 25,000 25 25 25 25 25 25 25 25 25 25 25 25 25 25

PO10-1.2 Pearson Correlation ,711** 1,000 ,811** ,611** ,332 ,466* ,612** ,554** ,459* ,607** ,620** ,681** ,576** ,472* ,778**

Sig. (2-tailed) ,000 ,000 ,001 ,105 ,019 ,001 ,004 ,021 ,001 ,001 ,000 ,003 ,017 ,000

N 25 25,000 25 25 25 25 25 25 25 25 25 25 25 25 25

PO10-1.3 Pearson Correlation ,757** ,811** 1,000 ,725** ,269 ,570** ,700** ,683** ,561** ,647** ,722** ,686** ,520** ,580** ,846**

Sig. (2-tailed) ,000 ,000 ,000 ,193 ,003 ,000 ,000 ,004 ,000 ,000 ,000 ,008 ,002 ,000

N 25 25 25,000 25 25 25 25 25 25 25 25 25 25 25 25

PO10-1.4 Pearson Correlation ,760** ,611** ,725** 1,000 ,492* ,702** ,595** ,572** ,703** ,335 ,573** ,739** ,728** ,790** ,852**

Sig. (2-tailed) ,000 ,001 ,000 ,013 ,000 ,002 ,003 ,000 ,101 ,003 ,000 ,000 ,000 ,000

N 25 25 25 25,000 25 25 25 25 25 25 25 25 25 25 25

PO10-1.5 Pearson Correlation ,260 ,332 ,269 ,492* 1,000 ,647** ,551** ,415* ,307 ,104 ,142 ,367 ,486* ,364 ,504*

Sig. (2-tailed) ,209 ,105 ,193 ,013 ,000 ,004 ,039 ,135 ,620 ,499 ,071 ,014 ,074 ,010

N 25 25 25 25 25,000 25 25 25 25 25 25 25 25 25 25

PO10-1.6 Pearson Correlation ,484* ,466* ,570** ,702** ,647** 1,000 ,825** ,781** ,586** ,143 ,300 ,656** ,439* ,529** ,728**

Sig. (2-tailed) ,014 ,019 ,003 ,000 ,000 ,000 ,000 ,002 ,496 ,145 ,000 ,028 ,007 ,000

N 25 25 25 25 25 25,000 25 25 25 25 25 25 25 25 25

PO10-1.7 Pearson Correlation ,606** ,612** ,700** ,595** ,551** ,825** 1,000 ,848** ,528** ,441* ,521** ,634** ,440* ,547** ,793**

Sig. (2-tailed) ,001 ,001 ,000 ,002 ,004 ,000 ,000 ,007 ,027 ,008 ,001 ,028 ,005 ,000

N 25 25 25 25 25 25 25,000 25 25 25 25 25 25 25 25

PO10-1.8 Pearson Correlation ,552** ,554** ,683** ,572** ,415* ,781** ,848** 1,000 ,420* ,320 ,474* ,547** ,332 ,436* ,716**

Sig. (2-tailed) ,004 ,004 ,000 ,003 ,039 ,000 ,000 ,037 ,120 ,017 ,005 ,105 ,029 ,000

N 25 25 25 25 25 25 25 25,000 25 25 25 25 25 25 25

PO10-1.9 Pearson Correlation ,614** ,459* ,561** ,703** ,307 ,586** ,528** ,420* 1,000 ,613** ,732** ,849** ,782** ,831** ,822**

Sig. (2-tailed) ,001 ,021 ,004 ,000 ,135 ,002 ,007 ,037 ,001 ,000 ,000 ,000 ,000 ,000

N 25 25 25 25 25 25 25 25 25,000 25 25 25 25 25 25

PO10-1.10 Pearson Correlation ,511** ,607** ,647** ,335 ,104 ,143 ,441* ,320 ,613** 1,000 ,848** ,653** ,589** ,536** ,672**

Sig. (2-tailed) ,009 ,001 ,000 ,101 ,620 ,496 ,027 ,120 ,001 ,000 ,000 ,002 ,006 ,000

N 25 25 25 25 25 25 25 25 25 25,000 25 25 25 25 25

PO10-1.11 Pearson Correlation ,721** ,620** ,722** ,573** ,142 ,300 ,521** ,474* ,732** ,848** 1,000 ,743** ,775** ,802** ,829**

Sig. (2-tailed) ,000 ,001 ,000 ,003 ,499 ,145 ,008 ,017 ,000 ,000 ,000 ,000 ,000 ,000

N 25 25 25 25 25 25 25 25 25 25 25,000 25 25 25 25

PO10-1.12 Pearson Correlation ,695** ,681** ,686** ,739** ,367 ,656** ,634** ,547** ,849** ,653** ,743** 1,000 ,790** ,816** ,897**

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,071 ,000 ,001 ,005 ,000 ,000 ,000 ,000 ,000 ,000

N 25 25 25 25 25 25 25 25 25 25 25 25,000 25 25 25

PO10-1.13 Pearson Correlation ,684** ,576** ,520** ,728** ,486* ,439* ,440* ,332 ,782** ,589** ,775** ,790** 1,000 ,877** ,829**

Sig. (2-tailed) ,000 ,003 ,008 ,000 ,014 ,028 ,028 ,105 ,000 ,002 ,000 ,000 ,000 ,000

N 25 25 25 25 25 25 25 25 25 25 25 25 25,000 25 25

PO10-1.14 Pearson Correlation ,690** ,472* ,580** ,790** ,364 ,529** ,547** ,436* ,831** ,536** ,802** ,816** ,877** 1,000 ,851**

Sig. (2-tailed) ,000 ,017 ,002 ,000 ,074 ,007 ,005 ,029 ,000 ,006 ,000 ,000 ,000 ,000

N 25 25 25 25 25 25 25 25 25 25 25 25 25 25,000 25

PO10-Media Pearson Correlation ,837** ,778** ,846** ,852** ,504* ,728** ,793** ,716** ,822** ,672** ,829** ,897** ,829** ,851** 1,000

Sig. (2-tailed) ,000 ,000 ,000 ,000 ,010 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000 ,000

N 25 25 25 25 25 25 25 25 25 25 25 25 25 25 25,000


Tabela 64 – Serviços Integrados - Correlação entre Nível de Maturidade Organizacional dos Objectivos de Controlo do Processo PO10 (Gestão de Projectos).

Fonte: Autor.



PO10-1.1 Pearson Correlation 1,000 ,910** ,815** ,719** ,598* ,642* ,764** ,570 ,437 ,623* ,630* ,589* ,696* ,711** ,818**

Sig. (2-tailed) ,000 ,001 ,008 ,040 ,024 ,004 ,053 ,155 ,031 ,028 ,044 ,012 ,010 ,001

N 12,000 12 12 12 12 12 12 12 12 12 12 12 12 12 12

PO10-1.2 Pearson Correlation ,910** 1,000 ,772** ,745** ,711** ,711** ,851** ,714** ,550 ,562 ,740** ,713** ,795** ,693* ,883**

Sig. (2-tailed) ,000 ,003 ,005 ,010 ,010 ,000 ,009 ,064 ,057 ,006 ,009 ,002 ,012 ,000

N 12 12,000 12 12 12 12 12 12 12 12 12 12 12 12 12

PO10-1.3 Pearson Correlation ,815** ,772** 1,000 ,830** ,707* ,678* ,892** ,697* ,653* ,798** ,727** ,506 ,858** ,801** ,901**

Sig. (2-tailed) ,001 ,003 ,001 ,010 ,015 ,000 ,012 ,021 ,002 ,007 ,093 ,000 ,002 ,000

N 12 12 12,000 12 12 12 12 12 12 12 12 12 12 12 12

PO10-1.4 Pearson Correlation ,719** ,745** ,830** 1,000 ,529 ,855** ,813** ,601* ,573 ,725** ,917** ,710** ,668* ,925** ,900**

Sig. (2-tailed) ,008 ,005 ,001 ,077 ,000 ,001 ,039 ,051 ,008 ,000 ,010 ,018 ,000 ,000

N 12 12 12 12,000 12 12 12 12 12 12 12 12 12 12 12

PO10-1.5 Pearson Correlation ,598* ,711** ,707* ,529 1,000 ,502 ,716** ,753** ,547 ,423 ,520 ,365 ,877** ,605* ,726**

Sig. (2-tailed) ,040 ,010 ,010 ,077 ,096 ,009 ,005 ,066 ,171 ,083 ,243 ,000 ,037 ,007

N 12 12 12 12 12,000 12 12 12 12 12 12 12 12 12 12

PO10-1.6 Pearson Correlation ,642* ,711** ,678* ,855** ,502 1,000 ,751** ,783** ,401 ,645* ,734** ,613* ,573 ,768** ,818**

Sig. (2-tailed) ,024 ,010 ,015 ,000 ,096 ,005 ,003 ,196 ,024 ,007 ,034 ,051 ,004 ,001

N 12 12 12 12 12 12,000 12 12 12 12 12 12 12 12 12

PO10-1.7 Pearson Correlation ,764** ,851** ,892** ,813** ,716** ,751** 1,000 ,813** ,736** ,797** ,851** ,713** ,892** ,782** ,961**

Sig. (2-tailed) ,004 ,000 ,000 ,001 ,009 ,005 ,001 ,006 ,002 ,000 ,009 ,000 ,003 ,000

N 12 12 12 12 12 12 12,000 12 12 12 12 12 12 12 12

PO10-1.8 Pearson Correlation ,570 ,714** ,697* ,601* ,753** ,783** ,813** 1,000 ,621* ,654* ,590* ,415 ,785** ,575 ,800**

Sig. (2-tailed) ,053 ,009 ,012 ,039 ,005 ,003 ,001 ,031 ,021 ,044 ,180 ,003 ,050 ,002

N 12 12 12 12 12 12 12 12,000 12 12 12 12 12 12 12

PO10-1.9 Pearson Correlation ,437 ,550 ,653* ,573 ,547 ,401 ,736** ,621* 1,000 ,773** ,725** ,446 ,795** ,657* ,753**

Sig. (2-tailed) ,155 ,064 ,021 ,051 ,066 ,196 ,006 ,031 ,003 ,008 ,147 ,002 ,020 ,005

N 12 12 12 12 12 12 12 12 12,000 12 12 12 12 12 12

PO10-1.10 Pearson Correlation ,623* ,562 ,798** ,725** ,423 ,645* ,797** ,654* ,773** 1,000 ,731** ,556 ,734** ,806** ,836**

Sig. (2-tailed) ,031 ,057 ,002 ,008 ,171 ,024 ,002 ,021 ,003 ,007 ,060 ,007 ,002 ,001

N 12 12 12 12 12 12 12 12 12 12,000 12 12 12 12 12

PO10-1.11 Pearson Correlation ,630* ,740** ,727** ,917** ,520 ,734** ,851** ,590* ,725** ,731** 1,000 ,832** ,704* ,884** ,901**

Sig. (2-tailed) ,028 ,006 ,007 ,000 ,083 ,007 ,000 ,044 ,008 ,007 ,001 ,011 ,000 ,000

N 12 12 12 12 12 12 12 12 12 12 12,000 12 12 12 12

PO10-1.12 Pearson Correlation ,589* ,713** ,506 ,710** ,365 ,613* ,713** ,415 ,446 ,556 ,832** 1,000 ,574 ,710** ,751**

Sig. (2-tailed) ,044 ,009 ,093 ,010 ,243 ,034 ,009 ,180 ,147 ,060 ,001 ,051 ,010 ,005

N 12 12 12 12 12 12 12 12 12 12 12 12,000 12 12 12

PO10-1.13 Pearson Correlation ,696* ,795** ,858** ,668* ,877** ,573 ,892** ,785** ,795** ,734** ,704* ,574 1,000 ,747** ,894**

Sig. (2-tailed) ,012 ,002 ,000 ,018 ,000 ,051 ,000 ,003 ,002 ,007 ,011 ,051 ,005 ,000

N 12 12 12 12 12 12 12 12 12 12 12 12 12,000 12 12

PO10-1.14 Pearson Correlation ,711** ,693* ,801** ,925** ,605* ,768** ,782** ,575 ,657* ,806** ,884** ,710** ,747** 1,000 ,900**

Sig. (2-tailed) ,010 ,012 ,002 ,000 ,037 ,004 ,003 ,050 ,020 ,002 ,000 ,010 ,005 ,000

N 12 12 12 12 12 12 12 12 12 12 12 12 12 12,000 12

PO10-Media Pearson Correlation ,818** ,883** ,901** ,900** ,726** ,818** ,961** ,800** ,753** ,836** ,901** ,751** ,894** ,900** 1,000

Sig. (2-tailed) ,001 ,000 ,000 ,000 ,007 ,001 ,000 ,002 ,005 ,001 ,000 ,005 ,000 ,000

N 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12,000


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).

Fonte: Autor.

Avaliação da Maturidade Organizacional em Gestão de ... · desafio crescente no sector do estado...

Documents

Transcript of Avaliação da Maturidade Organizacional em Gestão de ... · desafio crescente no sector do estado...