Gestão de Projectos e Gestão da Manutenção nas ... · deﬁnic¸ao e fornecimento de determinado produto, ... 2.1 ISO/IEC 12207: ... 4.9 Actividades detalhadas do processo de

Gestão de Projectos e Gestão da Manutenção nasDirecções de Sistemas de Informação

Diogo Filipe Dos Reis Pinto

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Orientadores: Professor José Luís Brinquete BorbinhaEngenheiro Miguel Ângelo Cotrim Bentes

Júri

Presidente: Professor Miguel Nuno Dias Alves Pupo CorreiaOrientador: Professor José Luís Brinquete Borbinha

Vogal: Professora Maria do Rosário Gomes Osório Bernardo Ponces de Carvalho

Novembro 2015

ii

Agradecimentos

Em primeiro lugar gostaria de deixar um agradecimento especial ao meu orientador externo Miguel

Bentes, que me acompanhou durante toda a dissertacao, em especial durante os tres meses de

desenvolvimento da solucao, demonstrando um empenho, compromisso e dedicacao extraordinarios

e que me permitiram, alem de adquirir todo o conhecimento necessario ao desenvolvimento desta

dissertacao, desenvolver um conjunto de competencias tecnicas que de certo serao muito importantes

no meu crescimento profissional.

Gostaria tambem de deixar um agradecimento especial ao meu orientador interno, o professor Jose

Borbinha, pela sua disponibilidade e experiencia, orientando-me durante todo o processo e auxiliando-

me na melhoria contınua do meu trabalho.

Por ultimo gostaria de agradecer aos meus pais, a minha namorada e aos meus amigos por todo o

apoio incondicional demonstrado.

iii

iv

Resumo

E proposto um processo generico para a gestao de pedidos de projectos e manutencoes evolutivas

numa direccao de sistemas de informacao de uma organizacao. Assumindo a direccao de sistemas de

informacao como o principal stakeholder, esta proposta alinha entre si tres vistas: a vista de processos,

a vista de responsabilidades e a vista de informacao.

A gestao nos sistemas de informacao de uma organizacao requer a gestao destes pedidos em al-

inhamento com as expectativas do negocio e um conjunto de outros criterios (risco, prioridade, capaci-

dade da equipa). Estes pedidos devem ser geridos de acordo com um conjunto de processos definidos

ate a sua satisfacao, identificando que actividades devem ser executadas e quais as entidades envolvi-

das nas mesmas.

Esta arquitectura de processos foi desenvolvida utilizando o metodo Design Science Research

Methodology (DSRM), inicialmente considerando o caso real de uma organizacao, sendo depois gen-

eralizado de forma a torna-la reutilizavel para outras organizacoes. A proposta aplicada ao caso real

apresentado foi ainda alvo de uma avaliacao por parte dos stakeholders da organizacao.

Palavras-chave: Gestao de Sistemas de Informacao, Gestao de Projecto, Gestao da Manutencao,

Responsabilidades.

v

vi

Abstract

It is proposed a generic process for dealing with requests for new projects or for evolutionary main-

tenance in an information systems department of an organization. Assuming the information systems

department’s organization as the main stakeholder, the proposal considers the alignment of three views:

the processes, the responsibilities and the information.

Information systems management on an organization requires handling these requests in alignment

with business expectations and several other criteria (risk, priority, team capabilities). These requests

must then be managed accordingly to a set of defined processes until its fulfillment, stating what activities

must be executed and who must be the entities involved in those activities.

This process architecture was developed using the Design Science Research Methodology, first

considering the real case scenario of a real organization, and after generalized in order to make it

reusable for any potential organization. An assessment of the proposal concerning the real case also

was performed by stakeholders of the real organization.

Keywords: Information Systems Management, Project Management, Maintenance Manage-

ment, Responsibilities.

vii

viii

Glossario

Arquitectura Principais conceitos e propriedades de um sistema de

acordo com o contexto em que este existe, englobando o

conjunto dos seus elementos e relacoes.

Gestao de Portfolios Escolha de programas e projectos, prioritizando-os e con-

trolando as dependencias entre si, segundo a estrategia da

organizacao.

Gestao de Programas Harmoniza os varios projectos ou sub-programas de forma

a atingir objectivos e benefıcios especıficos do programa.

Gestao de Projectos Aplicacao de metodos, ferramentas, tecnicas e com-

petencias a um projecto. E realizada atraves de proces-

sos, que sao seleccionados e aplicados de acordo com a

governacao de projectos conduzida pela organizacao.

Governacao de Projectos Fornece ao gestor de projecto e as respectivas equipas um

conjunto de processos, ferramentas e modelos de decisao

para a gestao dos projectos, enquanto permite o suporte e

controlo do sucesso dos mesmos.

Governacao A forma de controlo de uma organizacao visando o alcance

dos objetivos da mesma. Corresponde, entre outros as-

pectos, a definicao da estrutura de gestao de projectos, as

polıticas e metodos a utilizar, a definicao de responsabili-

dades e tomadas de decisao, a gestao de interaccoes e a

comunicacao e escalamento de problemas e riscos.

Manutencao Adaptativa Modificacao do software apos a sua entrega, de forma

a mante-lo correcto e em execucao num ambiente de

execucao alterado ou em constante evolucao.

Manutencao Correctiva Modificacao reactiva do software apos a entrega, de forma

a corrigir um problema encontrado na sua utilizacao.

Manutencao Perfectiva Modificacao do software apos a entrega de forma a detec-

tar e corrigir falhas latentes no mesmo antes destas falhas

serem detectadas.

Manutencao Preventiva Modificacao do software apos a entrega, de forma a de-

tectar e corrigir falhas latentes no mesmo antes destas se

tornarem falhas operacionais.

Manutencao Conjunto de activifdades realizadas para a implementacao

de uma modificacao apos entrega de uma solucao, de

forma a corrigir falhas da mesma.

ix

Operacoes Actividades com caracter repetitivo associadas a aspec-

tos de operacao e manutencao de sistemas ou produtos

fornecidos pela organizacao.

Portfolio Conjunto de projectos, programas, sub-portfolios e

operacoes geridos em conjunto de forma a atingir objec-

tivos estrategicos da organizacao.

Processo de Negocio Conjunto de actividades e tarefas relacionadas entre si e

coordenadas de forma a alcancar determinados objectivos

de negocio.

Processos de Entrega Nao sao unicos a gestao de projecto, e correspondem a

definicao e fornecimento de determinado produto, resul-

tado ou servico, dependendo do tipo de entregavel a que

se destina.

Processos de Gestao de Projecto Especıficos a gestao de projecto e determinam de que

forma as actividades a aplicar na gestao de projecto sao

conduzidas.

Processos de Suporte Nao sao unicos a gestao de projecto,fornecendo suporte

aos processos de gestao de projecto e de entrega em

areas como a area logıstica, a area financeira ou a area

de seguranca.

Programa Agrupado em portfolios e composto por sub-programas,

projectos e outras actividades que sao geridas de forma

coordenada para suportar o respectivo portfolio.

Projecto Conjunto unico de actividades coordenadas e controladas

com uma data de inıcio e fim definidas, executadas de

forma a alcancar um conjunto de objectivos estabelecidos

para o projecto.

Risco Conjunto de factores e influencias internas ou externas que

tornam incerto o alcance dos objectivos da organizacao.

Issue Acontecimento ocorrido e nao planeado, sendo necessario

proceder a sua gestao. Pode ter origem num risco que

tenha ocorrido ou qualquer tipo de nao-conformidade com

planos ou requisitos do projecto.

Software Parte integrante de um sistema, executando uma determi-

nada funcao neste contexto.

Stakeholder Elemento que possui informacoes e um conjunto de inter-

esses relativos ao projecto e ao sucesso do mesmo, sendo

parte integrante de todo o processo de gestao de projecto.

x

Indice

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Indice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Definicao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Metodo de Investigacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Fundamentos 7

2.1 ISO/IEC 12207: Software Life Cycle Processes . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2 ISO/IEC 14764: Software Life Cycle Processes - Maintenance . . . . . . . . . . . . . . . 10

2.3 ISO 21500: Guide on Project Management . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 PMBOK: Project Management Book of Knowledge . . . . . . . . . . . . . . . . . . . . . . 14

2.5 Referencias Complementares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.1 COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5.2 ITIL v3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.3 ISO 31000 - Risk Management - Principles and Guidelines . . . . . . . . . . . . . 19

3 Analise do Problema 22

3.1 Contextualizacao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.2 Motivacao e Contexto Pratico do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Definicao Concreta do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Solucao 28

4.1 Arquitectura de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.1.1 Vista de Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2 Vista de Responsabilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

xi

4.1.3 Vista de Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.2 Fase de Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32




4.3 Fase de Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39




4.4 Fase de Implementacao e Controlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46


4.4.1.1 Controlo Semanal do Projecto . . . . . . . . . . . . . . . . . . . . . . . . 47

4.4.1.2 Controlo Mensal do Projecto . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.4.1.3 Gestao de Riscos do Projecto . . . . . . . . . . . . . . . . . . . . . . . . 50

4.4.1.4 Gestao de Issues do Projecto . . . . . . . . . . . . . . . . . . . . . . . . 51

4.4.1.5 Gestao de Alteracoes do Projecto . . . . . . . . . . . . . . . . . . . . . . 53



4.5 Fase de Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59




5 Avaliacao 65

5.1 Avaliacao com Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.2 Mapeamento com Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.1 Fase de Oportunidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.2.2 Fase de Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.2.3 Fase de Implementacao e Controlo . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.2.4 Fase de Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6 Conclusao e Trabalho Futuro 74

Bibliografia 77

A Apendices 78

A.1 Documentos de Suporte da Fase de Oportunidade . . . . . . . . . . . . . . . . . . . . . . 78

A.2 Documentos de Suporte da Fase de Planeamento . . . . . . . . . . . . . . . . . . . . . . 79

A.3 Documentos de Suporte da Fase de Implementacao e Controlo . . . . . . . . . . . . . . . 80

A.4 Documentos de Suporte da Fase de Handover . . . . . . . . . . . . . . . . . . . . . . . . 81

A.5 PMBOK - Processos de Gestao de Projecto . . . . . . . . . . . . . . . . . . . . . . . . . . 82

xii

Lista de Tabelas

3.1 Processos de projecto e de compra considerados para o desenho da arquitectura. . . . . 26

4.1 Actividades detalhadas de identificacao e classificacao da oportunidade. . . . . . . . . . 34

4.2 Actividades detalhadas de analise da oportunidade e integracao em portfolio de projectos. 35

4.3 Matriz de responsabilidades das actividades de identificacao e analise da oportunidade. . 36

4.4 Matriz de responsabilidades das actividades de analise da oportunidade e integracao em

portfolio de projectos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.5 Matriz CRUF dos documentos de suporte da fase de oportunidade. . . . . . . . . . . . . 39

4.6 Actividades detalhadas do procedimento de compra. . . . . . . . . . . . . . . . . . . . . . 42

4.7 Vista de responsabilidades detalhada do procedimento de compra na fase de planeamento. 45

4.8 Matriz CRUF dos documentos de suporte ao processo na fase de planeamento. . . . . . 47

4.9 Actividades detalhadas do processo de controlo semanal do projecto. . . . . . . . . . . . 49

4.10 Actividades detalhadas do processo de controlo mensal do projecto. . . . . . . . . . . . . 50

4.11 Actividades detalhadas do processo de gestao de risco do projecto. . . . . . . . . . . . . 52

4.12 Vista de responsabilidades dos processos de controlo semanal e mensal do projecto. . . 56

4.13 Matriz CRUF dos documentos de suporte do processo de gestao semanal do projecto. . 58

4.14 Matriz CRUF dos documentos de suporte do processo de gestao mensal do projecto. . . 58

4.15 Matriz CRUF dos documentos de suporte do processo de gestao de riscos do projecto. . 59

4.16 Actividades detalhadas de aceitacao do projecto. . . . . . . . . . . . . . . . . . . . . . . . 61

4.17 Vista de responsabilidades das actividades de aceitacao do projecto. . . . . . . . . . . . 63

4.18 Matriz CRUF dos documentos de suporte da fase de handover do processo. . . . . . . . 64

5.1 Mapeamento com referencias relativo a fase de oportunidade. . . . . . . . . . . . . . . . 69

5.2 Mapeamento com referencias relativo a fase de planeamento. . . . . . . . . . . . . . . . 71

5.3 Mapeamento com referencias relativo a fase de implementacao e controlo. . . . . . . . . 72

5.4 Mapeamento com referencias relativo a fase de handover. . . . . . . . . . . . . . . . . . . 73

A.1 Documentos de suporte ao processo relativos a fase de oportunidade. . . . . . . . . . . . 78

A.2 Documentos de suporte ao processo relativos a fase de Planeamento. . . . . . . . . . . . 79

A.3 Descricao dos documentos de suporte ao processo relativos a fase de implementacao e

controlo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.4 Descricao dos documentos de suporte ao processo relativos a fase de handover. . . . . . 81

xiii

xiv

Lista de Figuras

1.1 Mapeamento das fases do DSRM para o trabalho realizado. . . . . . . . . . . . . . . . . . 5

2.1 Processos do ciclo de vida do software identificados pela ISO/IEC 12207. Extraıdo de [8]. 9

2.2 Tipos de pedidos de alteracao. Extraido de [7]. . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Contexto da gestao de projectos na organizacao. Extraıdo de [6]. . . . . . . . . . . . . . . 12

2.4 Processos de gestao de projecto segundo a ISO 21500. Extraıdo de [6]. . . . . . . . . . . 14

2.5 Elementos facilitadores da governacao identificados pelo COBIT. Extraıdo de [3]. . . . . . 17

2.6 Framework de gestao de risco proposta pela ISO 31000. Extraıdo de [5]. . . . . . . . . . 20

2.7 Processos de gestao de risco identificados pela ISO 31000. Extraıdo de [5]. . . . . . . . 21

3.1 Estrutura da organizacao considerada como caso real. . . . . . . . . . . . . . . . . . . . 24

4.1 Modelo conceptual da arquitectura de processos. Extraıdo de [9]. . . . . . . . . . . . . . 29

4.2 Fluxo completo do processo de gestao de projectos e manutencoes. . . . . . . . . . . . . 30

4.3 Fluxo do processo relativo a fase de oportunidade. . . . . . . . . . . . . . . . . . . . . . . 33

4.4 Fluxo do processo relativo a gestao de stakeholders, riscos e comunicacoes na fase de

planeamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.5 Fluxo do processo relativo ao procedimento de compra e gestao de calendario e de custos. 41

4.6 Fluxo do processo de controlo semanal do projecto. . . . . . . . . . . . . . . . . . . . . . 48

4.7 Fluxo do processo de controlo mensal do projecto. . . . . . . . . . . . . . . . . . . . . . . 49

4.8 Fluxo do processo de identificacao e analise do risco. . . . . . . . . . . . . . . . . . . . . 51

4.9 Fluxo do processo de tratamento do risco. . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.10 Fluxo do processo de identificacao e gestao de issues escalados. . . . . . . . . . . . . . 53

4.11 Fluxo do processo de gestao de issues nao-escalados e fecho do issue. . . . . . . . . . . 53

4.12 Fluxo do processo de gestao de alteracoes relativo ao planeamento e aprovacao da

alteracao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.13 Fluxo do processo de gestao de alteracoes relativo ao controlo e fecho da alteracao. . . . 55

4.14 Fluxo do processo relativo a aceitacao do projecto. . . . . . . . . . . . . . . . . . . . . . . 60

4.15 Fluxo do processo relativo a passagem a producao e encerramento do projecto. . . . . . 62

A.1 Processos definidos pelo PMBOK. Extraıdo de [2]. . . . . . . . . . . . . . . . . . . . . . . 82

xv

xvi

Capıtulo 1

Introducao

Neste capıtulo e feita uma introducao ao tema da gestao de projectos e manutencoes nas direccoes dos

sistemas de informacao. Pretende-se realizar uma contextualizacao do tema, que tem vindo a ter um

maior destaque na area dos sistemas de informacao, motivado pela necessidade das organizacoes de

possuir processos bem definidos para a gestao de actividades de execucao de projectos e manutencoes,

garantindo o alcance dos seus objectivos de negocio.

Pretende-se ainda apresentar quais os principais objectivos da solucao a desenvolver e um conjunto

de questoes que guiam todo o metodo de desenvolvimento. Estas questoes serao fundamentais na

avaliacao da solucao e da satisfacao dos requisitos do problema.

Todo o trabalho realizado foi conduzido por um metodo de investigacao, o Design Science Research

Metodology (DSRM) [16], amplamente utilizado na definicao e validacao de solucoes para problemas

na area dos sistemas de informacao, e adaptado no contexto deste trabalho de forma a ir ao encontro

dos seus objectivos.

1.1 Motivacao

Um dos aspectos importantes para uma organizacao ganhar vantagem competitiva face a concorrencia

e na forma como lida com a recepcao e gestao de pedidos de execucao de projectos e manutencoes.

Ha uma necessidade fundamental de classificar todos os pedidos em termos de oportunidades e valor

para o negocio, bem como o risco associado a sua aceitacao pela organizacao, tornando um pedido

numa oportunidade de negocio. Uma correcta analise do pedido e da consequente oportunidade que

apresenta a organizacao sera fundamental para garantir o sucesso no caso da sua aceitacao.

Alem da capacidade de analise de pedidos, a organizacao necessita de possuir processos bem

definidos para a gestao dos mesmos. Quando um novo pedido e apresentado a organizacao, deve ser

gerido de acordo com um processo predefinido que, independentemente do seu caracter ou da sua

origem, defina actividades (e respectivos inputs e outputs) e responsabilidades durante todo o ciclo de

vida do pedido ate a sua satisfacao.

Ao longo dos anos, profissionais da area dos sistemas de informacao definiram um conjunto de

1

frameworks e guias, numa tentativa de fornecer e normalizar praticas de gestao dos sistemas de

informacao. Tendo em conta o estado de arte actual nesta area, a ISO 21500 apresenta-se como a

norma internacional orientada a gestao de projectos. Considerando a definicao fornecida pela propria

ISO (Iternational Standard Organization), a ISO 21500 fornece um conjunto de praticas aconselhadas

na gestao de projectos que podem ser utilizadas por qualquer tipo de organizacao, independentemente

da sua area de servico ou do tipo de projecto, complexidade ou duracao. Nao define actividades es-

pecıficas a executar, apresentando uma visao orientada aos processos que devem ser executados

durante toda o ciclo de vida do projecto e focando-se nos inputs e outputs de cada processo.

A utilizacao do Project Management Book Of Knowledge (PMBOK), um dos guias de gestao de

projecto amplamente aceite por profissionais de todas as areas de conhecimento como uma referencia

em processos de gestao de projecto, complementa de forma extensa a ISO 21500, apresentando uma

correspondencia quase perfeita no que ao ambito dos processos diz respeito. Porem, apresenta um

maior nıvel de detalhe e identifica ainda um conjunto de tecnicas e ferramentas a aplicar no conjunto

de processos de gestao apresentados.

Considerando a area da gestao da manutencao, a norma ISO/IEC 14764 define os processos de

manutencao no ciclo de vida do software e servicos desenvolvidos por uma organizacao, cobrindo

as fases de planeamento, execucao, controlo, revisao e avaliacao de manutencoes. Corresponde a

especializacao dos processos de manutencao identificados por outra norma, a ISO/IEC 12207, que

identifica os processos do ciclo de vida do software e servicos, tambem analisada na definicao dos

processos a considerar no ambito da solucao a desenvolver.

Apesar de uma cobertura quase completa do ciclo de vida de projectos e manutencoes, aspectos

mais intrınsecos a organizacao, como a recepcao de pedidos ou a aceitacao de produtos e servicos pelo

cliente, nao se encontram explıcitos nestas referencias, sendo necessario considerar como referencia

secundaria o COBIT 5, orientado a gestao e governacao dos sistemas de informacao na organizacao. O

ITIL, um guia de praticas de gestao de servicos de tecnologias de informacao e a ISO 31000, orientada

a gestao de risco, tambem sao consideradas como referencias complementares fazendo face a lacunas

identificadas na cobertura de todos os processos de gestao de projectos e manutencoes.

Com o objectivo de estabelecer um processo de gestao de pedidos de execucao de projectos e

manutencoes, numa primeira fase sao analisadas um conjunto de referencias em processos orientados

a gestao de projectos e manutencoes na area dos sistemas de informacao, extraindo-se um conjunto

de conhecimentos necessarios para o desenho de todo o processo e definicao de responsabilidades,

atraves de uma arquitectura de processos que alinha entre si tres vistas, a vista de processos, a vista

de responsabilidades e a vista de informacao.

Alem destas referencias, sera tambem utilizado um caso real de uma organizacao como base para

o desenho do processo, que contemplara duas iteracoes: Uma arquitectura de processos aplicada ao

caso real da organizacao, traduzida num manual do processo especıfico, e uma arquitectura de proces-

sos mais generica, apresentada neste documento, e que procura ser aplicavel a um maior numero de

organizacoes, generalizando aspectos que sao intrınsecos ao caso real que estamos a considerar.

Para a avaliacao desta arquitectura serao utilizados dois metodos: a avaliacao com stakeholders,

2

metodo apresentado na seccao 5.1 e que procura ir ao encontro das expectativas dos stakeholders

tendo em conta o caso real da organizacao, e o metodo de mapeamento com referencias, apresentado

na seccao 5.2, que consiste num metodo teorico de definicao de correspondencias dos processos

definidos na arquitectura com processos identificados nas principais referencias consideradas.

1.2 Definicao do Problema

O proposito deste trabalho e a definicao de um processo de referencia para a gestao de pedidos de

projectos e de manutencoes numa direccao dos sistemas de informacao. Neste ambito, considera-

se um projecto como um conjunto unico de actividades coordenadas e controladas com uma data de

inıcio e fim definidas, executadas de forma a alcancar um conjunto de objectivos estabelecidos para o

projecto. Uma manutencao corresponde a um conjunto de actividades realizadas para a implementacao

de uma modificacao apos entrega de uma solucao, de forma a corrigir falhas da mesma.

Considerando o caso real de uma organizacao, pretende-se definir, alem do fluxo do processo e

das actividades a executar, um conjunto de responsabilidades atribuıdas a estrutura organizacional da

organizacao bem como um conjunto de documentos de suporte ao processo.

Pretende-se ainda garantir a aplicabilidade da solucao atraves da sua generalizacao, possibilitando

a sua adaptacao a qualquer organizacao. Em suma, o objectivo e responder as seguintes questoes:

1. Questao 1 - Que processos (e correspondentes actividades) devem ser executados para a gestao

de pedidos de execucao de projectos e manutencoes?

2. Questao 2 - Quais as responsabilidades dos varios elementos da area de sistemas de informacao

em todo o processo?

3. Questao 3 - Quais os documentos que suportam todo o processo?

Alem das questoes de desenvolvimento definidas, foram tracados um conjunto de objectivos rela-

cionados com o desenho da solucao e os contrangimentos que a ela se aplicam, permitindo durante a

fase de avaliacao garantir o cumprimento de todos os objectivos estabelecidos:

• A solucao devera cumprir um prazo limitado de desenvolvimento, sendo necessario identificar um

conjunto de processos a considerar, nao sendo possıvel garantir uma extensibilidade da solucao

em todos os processos identificados pelas referencias.

• A arquitectura de processos a desenvolver devera garantir uma conformidade com um conjunto de

referencias na area da gestao de projectos e gestao de manutencoes, apresentadas no capıtulo

2, baseando-se nas melhores praticas de gestao.

• A arquitectura devera ser, alem de aplicavel ao caso real da organizacao considerado, adaptavel

a um conjunto de outras organizacoes, sendo necessario generalizar aspectos especıficos e

intrınsecos ao caso real analisado.

3

1.3 Metodo de Investigacao

De forma a conduzir todo o desenvolvimento foi utilizado o metodo de investigacao Design Science

Research Methodology (DSRM), apresentado no artigo A design science research methodology for

information systems research [16], e utilizado amplamenta na area dos sistemas de informacao para a

apresentacao e validacao de solucoes desenvolvidas.

Os sistemas de informacao retiram um conjunto de vantagens da aplicacao do DSRM a investigacao

na area, nomeadamente no desenvolvimento de solucoes para problemas da propria area e da sua

presenca nas organizacoes. Este metodo possui tes objectivos principais: Apresentar um metodo para

a conducao de investigacoes, definir como base da investigacao um conjunto de referencias literarias

que a suportam e fornecer aos investigadores um modelo mental dos resultados da investigacao.

O DSRM consiste num processo com caracter iterativo e composto por seis fases:

• Identificacao do problema e motivacao - Definicao da importancia do problema e da necessi-

dade de uma solucao;

• Definicao dos objectivos da solucao - Definicao dos requisitos que devem ser cumpridos pela

solucao a implementar;

• Desenho e desenvolvimento - Fase principal do processo na qual os artefactos da solucao sao

implementados para cumprir os requisitos estabelecidos. Esta fase possui um caracter iterativo

pois necessita de avaliacoes e revisoes aos artefactos. Ira receber feedback das fases seguintes.

• Demonstracao - Confirmacao da aplicacao dos artefactos aos requisitos do problema;

• Avaliacao - Medida do nıvel de satisfacao dos requisitos estabelecidos por parte dos artefactos

produzidos.

• Comunicacao - Documentacao e divulgacao dos artefactos como solucao do problema identifi-

cado.

Na figura 1.1 e possıvel observar a aplicacao do metodo ao trabalho realizado. A necessidade

de definicao de um processo para a gestao de projectos e manutencoes na direccao de sistemas de

informacao de uma organizacao apresentada como caso real assume o papel de entry point para todo

o processo:

• Identificacao do problema e motivacao - Analise do estado da arte na gestao de projectos e

manutencoes nas direccoes de sistemas de informacao, fazendo um levantamento dos principais

processos a considerar.

• Definicao dos objectivos da solucao - Desenho de uma arquitectura de processos para a gestao

de projectos e manutencoes aplicavel a um conjunto de direccoes de sistemas de informacao,

tendo como base o caso real de uma organizacao e o conjunto de stakeholders considerado.

Tendo em conta este objectivo, a arquitectura a definir possuira duas versoes:

4

Figura 1.1: Mapeamento das fases do DSRM para o trabalho realizado.

– Versao generalizada da arquitectura, apresentada no capıtulo 4 deste documento e que

generaliza aspectos intrınsecos as organizacoes e a sua estrutura organizacional.

– Versao aplicada ao caso real da organizacao, que corresponde ao manual do processo

produzido na fase de comunicacao, e que aplica a arquitectura generalizada ao caso real da

organizacao.

• Desenho e desenvolvimento - Definicao da arquitectura de processos que alinha entre si tres

vistas: a vista de processos, a vista de responsabilidades e a vista de informacao, indo ao encon-

tro do conjunto de constrangimentos ao problema identificados.

• Demonstracao - Producao de um manual do processo com a definicao de uma arquitectura

aplicada ao caso real da organizacao considerado, alvo de um processo iterativo de validacao

com os stakeholders considerados.

• Avaliacao - Aplicacao de dois metodos de avaliacao da arquitectura de processos. A avaliacao

com stakeholders, aplicavel as duas versoes da arquitectura produzidas e o mapeamento com

referencias, aplicado a versao generalizada da arquitectura.

• Comunicacao - Producao do manual do processo, relativo a versao da arquitectura de proces-

sos aplicada ao caso real da organizacao, e a escrita da dissertacao que apresenta a versao

generalizada da arquitectura desenvolvida.

1.4 Estrutura do Documento

Este documento encontra-se organizado da seguinte forma:

1. O capıtulo 1 introduz o problema a solucionar, apresentando-se uma contextualizacao do tema

e motivacao do problema, sendo tambem apresentado o metodo de investigacao utilizado no

desenvolvimento da solucao.

5

2. O capıtulo 2 apresenta um conjunto de fundamentos na area de gestao de projectos e manutencoes,

identificando um conjunto de referencias consideradas como normas ou guias de boas praticas na

area e a partir das quais e feito todo o desenvolvimento da solucao. Neste capıtulo serao apresen-

tados as normas internacionais ISO/IEC 12207, ISO/IEC 14764 e ISO 21500 e o PMBOK, sendo

tambem analisadas como referencias complementares o COBIT 5, o ITIL V3 e a ISO 31000.

3. O capıtulo 3 apresenta em maior detalhe o problema abordado, contextualizando-o e definindo

alguns constragimentos que introduz a solucao a desenvolver. Neste capıtulo e tambem apresen-

tado o caso real da organizacao que sera utilizado para demonstracao da solucao.

4. O capıtulo 4 apresenta a solucao desenvolvida, identificando de que forma endereca o problema

considerado, sendo detalhadas algumas decisoes de desenvolvimento e os aspectos mais impor-

tantes da arquitectura desenvolvida.

5. No capıtulo 5 e apresentada a avaliacao da solucao, procedendo-se a utilizacao de dois metodos

de avaliacao: avaliacao com stakeholders e o mapeamento com referencias.

6. No capıtulo 6 sao apresentadas as principais conclusoes obtidas e identificadas propostas de

trabalho futuro no ambito do trabalho desenvolvido.

6

Capıtulo 2

Fundamentos

Neste capıtulo sao apresentadas um conjunto de referencias na area da gestao de projectos e gestao

de manutencoes, a utilizar como base de conhecimento na definicao da arquitectura de processos. As

frameworks, normas e guias apresentadas de seguida reunem um conjunto de conhecimentos consid-

erados por profissionais da area como as melhores praticas de gestao de projectos e manutencoes,

sendo necessario seleccionar o conjunto de conhecimentos efectivos a aplicar, de acordo com os ob-

jectivos definidos para a arquitectura a desenvolver.

A primeira referencia a analisar e a norma internacional ISO/IEC 12207 - Software Life Cycle Pro-

cesses [8]. Esta norma define uma framework de processsos a aplicar durante o ciclo de vida do

software e de servicos, sendo util na identificacao das areas de processos a considerar na definicao

da arquitectura de processsos. Directamente relacionada com esta norma, a ISO/IEC 14764: Soft-

ware Life Cycle Processes - Maintenance [7] detalha os processos de manutencao identificados pela

ISO/IEC 12207, apresentando processos, actividades e conceitos que cobrem todo o ciclo de vida das

manutencoes.

Na area da gestao de projectos, a ISO 21500: Guide on Project Management [6] e o Project Man-

agement Book of Knowledge [2] constituem as principais referencias, identificando boas praticas e

processos aplicaveis a um vasto conjunto de organizacoes. Definem toda a base de conhecimento

a partir da qual sera desenhada a arquitectura, desde as areas de processos a desenvolver ate aos

documentos de suporte a considerar.

Alem destas referencias, e tendo em conta algumas lacunas em termos de classificacao e entregas

de pedidos, bem como de alguns aspectos especıficos da gestao de projecto, consideram-se tambem

um conjunto de referencias complementares, detalhadas na seccao 2.5.

2.1 ISO/IEC 12207: Software Life Cycle Processes

Esta norma internacional estabelece uma framework de processos a executar durante o ciclo de vida do

software e servicos, apresentando processos, actividades e tarefas que deverao ser executadas tanto

na sua compra e fornecimento bem como durante o seu desenvolvimento, operacao e manutencao.

7

O principal objectivo desta norma e facilitar a comunicacao entre todos os participantes no ciclo de

vida do software e servicos, garantindo que as organizacoes envolvidas no seu fornecimento e compra

se encontrem perfeitamente alinhadas em termos de processos a desenvolver bem como de objectivos

e resultados a alcancar.

Os conceitos de sistema e software definem o contexto dos processos identificados por esta norma.

De acordo com esta norma, o software corresponde a uma parte integrante de um sistema, execu-

tando uma determinada funcao neste contexto. Esta relacao torna-se mais perceptıvel, por exemplo, na

analise de requisitos, em que os requisitos do software sao extraıdos a partir da analise de requisitos

do sistema. Apesar desta distincao, existem casos em que a separacao entre o sistema e o software

que o compoe e praticamente residual.

De acordo com a ISO 12207, o ciclo de vida de software e servicos inicia-se com uma ideia ou

necessidade a colmatar e termina com a manutencao desse mesmo software ou servico. A framework e

consitutida por um conjunto de processos e relacoes, identificados de acordo com os princıpios basicos

de coesao (os processos devem estar interligados entre si de forma a garantir uma framework coesa) e

de responsabilidade (o desenho e implementacao de um processo e responsabilidade da organizacao

ao qual se destina).

O conjunto de processos e dividido numa primeira fase entre processos no contexto do sistema e

processos no contexto de software, sendo no seu conjunto agrupados em 7 grupos de processos. Cada

processo e descrito em termos dos seus objectivos, resultados esperados e actividades a executar para

alcancar esses objectivos. Os processos dividem-se nos seguintes grupos:

• Processos de acordo - Processos necessarios ao estabelecimento de acordos de compra e

fornecimento de software ou servicos entre duas organizacoes.

• Processos organizacionais - Processos para a gestao da capacidade de compra e fornecimento

de software e servicos atraves da execucao de projectos. Estes processos garantem a posse de

recursos e infraestruturas necessarias ao suporte dos projectos e a satisfacao dos objectivos da

organizacao.

• Processos de projecto - Processos para a definicao de planos do projecto, para a avaliacao da

performance e progresso relativamente aos planos e para o controlo da execucao do projecto ate

ao seu encerramento.

• Processos tecnicos - Processos que acompanham o ciclo de vida de um sistema, desde a

definicao dos requisitos ao desenho e implementacao do mesmo. Inclui tambem processos rela-

tivos a utilizacao do sistema pelos utilizadores.

• Processos de implementacao de software - Processos utilizados para produzir um elemento

especıfico de um sistema implementado na forma de software. Estes processos transformam um

conjunto de procedimentos, interfaces e constrangimentos numa implementacao de um elemento

de um sistema que satisfaz um conjunto de requisitos extraidos dos requisitos do sistema.

8

• Processos de suporte de software - Processos focados num conjunto de actividades de suporte

aos processos de implementacao de software, contribuındo para o seu sucesso e para a qualidade

do projecto.

• Processos de reutilizacao de software - Processos que suportam a capacidade da organizacao

de reutilizar software de um dado projecto noutros projectos ou contextos em que possa ser

aplicado. Estes processos sao executados foram do ambito de um projecto particular, sendo

comum a todos os projectos.

Na figura 2.1 podemos observar os grupos de processos identificados anteriormente, sendo tambem

apresentado os processos que fazem parte de cada grupo.

Figura 2.1: Processos do ciclo de vida do software identificados pela ISO/IEC 12207. Extraıdo de [8].

Esta norma nao detalha os processos em termos de detalhes de implementacao, nao os pre-

screvendo a organizacao e deixando espaco de decisao para escolhas de implementacao. Alem disso,

o conjunto de processos apresentado e suficientemente generico de modo a permitir a sua adopcao e

adaptabilidade a um conjunto vasto de organizacoes, que actuem em diferentes contextos.

Esta norma internacional possui especial interesse na medida em que identifica o grupo de proces-

sos que contempla todas as fases do ciclo de vida de sistemas, que pretendemos cobrir com a arquitec-

tura a desenvolver. Tendo em conta os objectivos definidos, serao especialmente importantes os pro-

cessos de acordo, processos organizacionais e processos de projecto, que apresentam um foco mais

9

orientado a gestao do projecto do que a aspectos mais operacionais e especıficos a implementacao de

sistemas. Na seccao 3.3 esta norma sera utilizada na identificacao dos processos especıficos consid-

erados no desenvolvimento da solucao.

2.2 ISO/IEC 14764: Software Life Cycle Processes - Maintenance

A norma ISO/IEC 14764: Software Life Cycle Processes - Maintenance [7] corresponde a uma especializacao

do processo de manutencao identificado pela ISO/IEC 12207, apresentada acima, e define todo o pro-

cesso de planeamento, execucao, controlo, revisao e avaliacao de manutencoes. Focando-se apenas

na manutencao de software, esta norma aplica-se a qualquer contexto nesta area, independentemente

do tamanho, complexidade ou aplicacao do software.

Na figura 2.2 encontramos a definicao dos varios pedidos de alteracao considerados por esta norma

e que poderao ser apresentados durante a manutencao de um software. Um pedido generico de

alteracao e classificado como um pedido correctivo (correspondendo a uma alteracao reactiva prove-

niente de uma nao conformidade do software) ou um pedido de melhoria (correspondendo a uma

alteracao que visa a satisfacao de um novo requisito), sendo depois detalhado num dos seguintes

tipos de manutencao:

Figura 2.2: Tipos de pedidos de alteracao. Extraido de [7].

• Manutencao correctiva - Modificacao reactiva do software apos a entrega, de forma a corrigir

um problema encontrado na sua utilizacao.

• Manutencao preventiva - Modificacao do software apos a entrega, de forma a detectar e corrigir

falhas latentes no software antes destas se tornarem falhas operacionais.

• Manutencao adaptativa - Modificacao do software apos a sua entrega, de forma a mante-lo

correcto e em execucao num ambiente de execucao alterado ou em constante evolucao.

• Manutencao perfectiva - Modificacao do software apos a entrega de forma a detectar e corrigir

falhas latentes no software antes destas falhas serem detectadas.

O processo de manutencao apresentado nesta norma contem um conjunto de actividades e tare-

fas necessarias desenvolver, sendo a sua implementacao responsabilidade da area de manutencao

10

da organizacao, que deve garantir que todas as actividades se encontram implementadas e funcionais

antes de iniciar o desenvolvimento de software. Este processo devera ser iniciado assim que os requisi-

tos de manutencao surjam no ambito do projecto, dando inıcio ao desenvolvimento de planos e alocacao

de recursos. Esta norma define o seguinte processo de manutencao, dividido em seis sub-processos:

• Implementacao do processo - Nesta fase sao desenvolvidos os planos e procedimentos para

a execucao do processo de manutencao. O plano de manutencao deve ser desenvolvido em

paralelo com o plano de desenvolvimento, garantindo que toda a manutencao e planeada ainda

durante o desenvolvimento do software e que todas as interfaces de comunicacao entre equipas

de desenvolvimento e manutencao sao estabelecidas.

• Analise da manutencao - Este processo e os restantes sao apenas executados quando o soft-

ware transita para manutencao e pedidos de manutencao surjam. Sao analisados os pedidos

de manutencao, replicados e verificados possiveis problemas que deram origem ao pedido, anal-

isadas e documentadas opcoes para a implementacao da manutencao e obtida aprovacao para a

implementacao da solucao seleccionada.

• Implementacao da manutencao - Este processo corresponde ao desenvolvimento e teste da

manutencao realizada no software de forma a ir ao encontro do pedido de manutencao analisado

na fase anterior.

• Revisao e aceitacao da manutencao - Este processo assegura que as alteracoes ao software

foram as correctas e aceites pela entidade que requeriu a manutencao, de acordo com os proces-

sos definidos pela organizacao para esse efeito.

• Migracao - Processo que assegura a passagem do software para o ambiente de execucao em

conformidade com a ISO/IEC 12207, sendo desenvolvido um plano de migracao para o acompan-

hamento de todo o processo.

• Retirada do software - Processo para a saıda de funcionamento do software, que devera ser su-

portado por uma analise de necessidade. Devem ser identificadas todas as actividades necessarias

realizar nesta fase pelos responsaveis da manutencao e desenvolver um plano de saıda de fun-

cionamento.

Todo o processo de manutencao detalhado nesta norma possui um caracter mais operacional, iden-

tificando tarefas especıficas a realizar em cada sub-processo de forma a ir ao encontro do ciclo de

vida do software identificado pela ISO/IEC 12207. Tendo em conta os objectivos estabelecidos, nao

se pretende uma visao tao operacional do processo, razao pela qual se encontra especial interesse

na estrategia de manutencao de software identificada nesta norma. Esta estrategia identifica quais os

recursos humanos e materiais necessarios para fornecer a manutencao, dividindo-se nos seguintes

elementos:

• Conceito da manutencao - Corresponde ao primeiro passo de desenvolvimento de uma es-

trategia de manutencao, devendo ser identificado o seu ambito, o processo de implementacao e

11

responsaveis e realizada uma estimativa de custos da manutencao.

• Plano de manutencao - Corresponde ao planeamento das actividades de manutencao e a aquisicao

de todos os recursos necessarios de forma a que estes se encontrem disponıveis no momento

da transicao do software para manutencao. O planeamento e iniciado assim que o conceito da

manutencao e definido e termina com a definicao do plano de manutencao.

• Analise de recursos - Corresponde a definicao de todos os recursos necessarios a implementacao

da manutencao. O responsavel pela manutencao devera determinar os recursos humanos, tec-

nologicos e financeiros necessarios.

A norma ISO/IEC 14764 apresenta-se como a referencia completa em toda a area de gestao da

manutencao, identificando todos os processos de manutencao necessarios durante o ciclo de vida do

software, atraves de uma visao mais operacional da manutencao, e apresentando processos para a

definicao da estrategia de manutencao de software, com um caracter mais estrategico.

2.3 ISO 21500: Guide on Project Management

A ISO 21500:Guide on Project Management [6] reune um conjunto de conceitos alto-nıvel e processos

que sao considerados boas praticas na area de gestao de projecto. Pode ser utilizada por qualquer

tipo de organizacao, independentemente do seu contexto (publica, privada, comunitaria) e do tipo, com-

plexidade ou duracao de projectos levados a cabo. Um projecto e definido por esta norma como um

conjunto unico de actividades coordenadas e controladas com uma data de inıcio e fim definidas, ex-

ecutadas de forma a alcancar os objectivos do projecto. E ainda definido um conjunto de conceitos

e de relacoes entre eles, sendo possıvel definir um contexto de gestao de projectos dentro de uma

organizacao, apresentado na figura 2.3.

Figura 2.3: Contexto da gestao de projectos na organizacao. Extraıdo de [6].

12

Tendo em conta este contexto, a estrategia organizacional identifica um conjunto de oportunidades

que sao avaliadas e documentadas. Deste conjunto de oportunidades, apenas algumas sao aceites

para darem inicio a projectos, sendo desenvolvido o caso de negocio que representa a oportunidade em

termos de valor e objectivos para a organizacao. Esta fase corresponde ao conceito de governacao de

projecto, que e definido pela ISO 21500 como a forma como uma organizacao e orientada e controlada.

A governacao corresponde, entre outros aspectos, a definicao da estrutura de gestao de projectos,

as polıticas e metodos a utilizar, a definicao de responsabilidades e tomadas de decisao, a gestao de

interaccoes e a comunicacao e escalamento de problemas e riscos.

A gestao de projectos e definida como a aplicacao de metodos, ferramentas, tecnicas e com-

petencias a um projecto. E realizada atraves de processos, que sao seleccionados e adaptados a

governacao de projectos conduzida pela organizacao. Nesta norma sao identificados tres tipos de

processos:

• Processos de gestao de projecto - Especıficos a gestao de projecto e determinam de que forma

as actividades a aplicar na gestao de projecto sao conduzidas.

• Processos de entrega - Nao sao unicos a gestao de projecto, e correspondem a definicao e

fornecimento de determinado produto, resultado ou servico, dependendo do tipo de entregavel a

que se destina.

• Processos de suporte - Nao sao unicos a gestao de projecto, fornecendo suporte aos processos

de gestao de projecto e de entrega em areas como a logıstica, financeira ou seguranca.

No contexto da organizacao sao ainda apresentadas as operacoes, que diferem dos projectos

pelo seu caracter repetitivo e foco na realizacao de actividades repetidas, associadas a aspectos de

operacao e manutencao de sistemas ou produtos fornecidos pela organizacao. As actividades de

manutencao, embora nao especificadas nesta norma, sao consideradas tambem como operacoes.

Apesar de definir tres tipos de processos orientados a gestao de projecto, a ISO 21500 detalha

apenas os procesos de gestao de projecto, que devem ser usados como um todo durante o ciclo de

vida do projecto, que corresponde ao perıodo entre a data de inıcio e de fim do mesmo. Divide-se em

fases de acordo com pontos de decisao, que variam em funcao da organizacao a que se aplicam. No

final da ultima fase do projecto, todos os entregaveis do projecto devem encontrar-se finalizados.

O conjunto de processos a aplicar para a gestao de projectos deve ser seleccionado e detalhado de

acordo com os objectivos da organizacao, de forma a se encontrar alinhado com os mesmos. A ISO

21500 divide os processos de acordo com duas perspectivas diferentes, como grupos de processos e

como areas de conhecimento. O conjunto de processos identificados podem ser observados na figura

2.4. Para cada processo sao detalhados os seus objectivos, a descricao de actividades a realizar e um

conjunto de inputs e outputs do processo.

Esta norma internacional corresponde a principal referencia considerada na area da gestao de pro-

jecto. Cobre todo o ciclo de vida de um projecto, desde a definicao da oportunidade ate ao encerra-

mento. Porem, foca-se apenas em processos de gestao de projecto, nao detalhando os processos de

13

Figura 2.4: Processos de gestao de projecto segundo a ISO 21500. Extraıdo de [6].

governacao e que serao especialmente importantes para a classificacao de oportunidades. E tambem

considerado que um projecto termina com os processos de encerramento do projecto, nao detalhando

aspectos de aceitacao e entrega do mesmo.

Alem destas limitacoes, a ISO 21500 foca-se principalmente nos inputs e outputs de cada processo

identificado, nao detalhando o conteudo destes artefactos. A definicao de actividades de cada processo

tambem e limitada, sendo apenas apresentados alguns objectivos de alto nıvel do processo. Por esta

razao, e necessario considerar uma referencia mais completa no que a actividades a executar em cada

processo diz respeito.

2.4 PMBOK: Project Management Book of Knowledge

O Project Management Book of Knowledge (PMBOK) [2] corresponde a um guia de boas praticas na

gestao de projectos individuais, definindo tambem um conjunto de conceitos relacionados com a area.

E considerado como o guia de referencia na gestao de projectos, independentemente da area ou do

tipo, complexidade ou tamanho do projecto. Resulta da experiencia de profissionais na area ao longo

dos anos bem como da aplicacao das praticas em projectos reais.

O PBMOK define um projecto como um esforco temporario realizado para criar um produto, servico

14

ou resultado unico. A natureza temporaria do projecto e definida por uma data de inıcio e de fim. O

encerramento do projecto e ditado pela satisfacao dos objectivos do mesmo ou por um fim previo devido

a impossibilidade de cumprimentos desses objectivos.

Um conceito importante referir e a relacao entre portfolios, programas e projectos. Um portfolio

corresponde a um conjunto de projectos, programas, sub-portfolios e operacoes geridos em conjunto

de forma a atingir objectivos estrategicos. Os programas sao agrupados em portfolios e sao compostos

por sub-programas, projectos e outras actividades que sao geridas de forma coordenada para suportar

o respectivo portfolio. Os projectos, que podem estar contidos num programa, pertencem sempre a um

portfolio. Apesar de os projectos e programas nao estarem directamente ligados entre si, relacionam-se

com a estrategia implementada pela organizacao atraves do portfolio.

Tendo em conta estes conceitos e importante compreender de que forma a sua gestao e distinta

em termos do seu contributo para os objectivos estrategicos da organizacao. A gestao de portfolio

implementa a estrategia da organizacao atraves da escolha de programas e projectos, prioritizando-

os e controlando as dependencias entre si. A gestao de programas harmoniza os varios projectos ou

sub-programas de forma a atingir objectivos e benefıcios especıficos. A gestao de projecto desenvolve

e implementa planos para alcancar objectivos especıficos dentro do ambito do projecto e que sao

conduzidos pela gestao de programas e de portfolios.

A governacao de projectos encontra-se de acordo com o modelo de governacao da organizacao

e fornece ao gestor de projecto e as respectivas equipas um conjunto de processos, ferramentas e

modelos de decisao para gestao dos projectos, enquanto permite o suporte e controlo do sucesso dos

mesmos. A governacao de projectos e distinta da governacao da organizacao, embora estejam em

sintonia para a satisfacao dos objectivos estrategicos da organizacao. A governacao da organizacao

foca-se mais em aspectos estrategicos do negocio e no alcance dos seus objectivos.

O PMBOK apresenta alguns exemplos de elementos que fazem parte da governacao de projectos,

dos quais se destacam os criterios de aceitacao de projectos, processos para a identificacao, escala-

mento, e resolucao de problemas no projecto, processos para a comunicacao de informacao, processos

para tomada de decisoes, processos para definicao e revisao de fases do projecto e processos para

definicao e revisao de alteracoes ao orcamento, ambito, qualidade e calendario.

Segundo o PMBOK, a gestao de projectos e a aplicacao do conhecimento, ferramentas e tecnicas

a actividades de projecto de forma a ir ao encontro dos requisitos identificados. E realizada atraves da

aplicacao e integracao de 47 processos agrupados logicamente e categorizados em cinco grupos de

processos: Processos de iniciacao, processos de planeamento, processos de execucao, processos de

monitorizacao e controlo e processos de encerramento.

Os processos de iniciacao correspondem a definicao de um novo pojecto ou de uma nova fase de

um projecto ja existente, atraves da autorizacao para o inıcio do projecto ou da fase. Os processos de

planeamento correspondem a definicao do ambito, objectivos e actividades para execucao do projecto.

Os processos de execucao definem as actividades a realizar para cumprir o planeamento do projecto

e os respectivos objectivos. Os processos de monitorizacao e controlo definem o controlo, revisao e

monitorizacao do progresso do projecto enquanto que os processos de encerramento formalizam o fim

15

das actividades do projecto.

Alem da divisao dos processos por fases, o PMBOK tambem apresenta uma divisao por areas

de conhecimento, nomeadamente: Gestao da integracao, gestao de ambito, gestao de tempo, gestao

de custos, gestao de qualidade, gestao de recursos humanos, gestao de comunicacoes, gestao de

risco, gestao de compras e gestao de stakeholders. Esta divisao torna-se especialmente interessante

na medida em que nos permite seleccionar quais as areas que queremos cobrir na arquitectura a

desenvolver e aquelas que pretendemos abstrair. No anexo A.5 podemos observar todos os processos

identificados pelo PMBOK divididos por fases de projecto e areas de conhecimento.

Um aspecto importante na utilizacao desta referencia e o seu alinhamento com a ISO 21500, a

principal referencia de processos na gestao de projectos que estamos a considerar, sendo possıvel

encontrar, para todas as fases e areas de processos da ISO 21500, fases e areas de processos no

PMBOK, apresentadas em maior detalhe em termos de actividades, ferramentas e tecnicas a aplicar

no processo.

2.5 Referencias Complementares

Tendo em conta as referencias anteriores e algumas lacunas em aspectos especıficos que pretende-

mos abordar, foi necessario considerar um conjunto de referencias complementares para colmatar es-

sas lacunas. Embora nao sejam aplicaveis na ıntegra, estas referencias detalham alguns aspectos

fundamentais para fornecer o conhecimento necessario a definicao do processo.

Uma das referencias a analisar e o COBIT 5 (Control Objectives for Information and Related Tec-

nhology ) [3], uma framework criada pela ISACA (Information Systems Audit and Control Association)

orientada a gestao e governacao nos sistemas de informacao. Esta referencia sera especialmente im-

portante na area da governacao de projectos, permitindo-nos definir o processo de recepcao e entrega

dos pedidos de projectos e manutencoes, que nao se encontra detalhado em nenhuma das referencias

anteriores.

Outra referencia importante a considerar e o ITIL V3 (Information Technology Infrastructure Library )

[15, 11, 13, 12, 14, 10], que define um conjunto de boas praticas na gestao de servicos de tecnolo-

gias de informacao. Tornou-se a principal referencia nesta area e foi adoptado por organizacoes em

todo o mundo, desde publicas a privadas, permitindo transformar capacidades de gestao de servicos

em mais-valias estrategicas. Apesar de nao estar directamente relacionado com a gestao de pro-

jecto, fornece um conjunto de conhecimentos em areas como a gestao de incidentes, problemas ou

alteracoes, encontrando-se facilmente uma correspondencia com a area da gestao de projectos.

Por ultimo, e considerando a gestao de risco como um tema complexo e de elevado interesse,

considerou-se a ISO 31000 [5], um conjunto de normas internacionais na gestao de risco, como uma re-

ferencia a considerar. Esta norma fornece uma framework e um conjunto de processos para a aplicacao

de princıpios de gestao de risco numa organizacao, independentemente do contexto em que actua.

16

2.5.1 COBIT 5

O COBIT 5 (Control Objectives for Information and Related Tecnhology) e uma framework criada pela

ISACA (Information Systems Audit and Control Association) que auxilia as organizacoes a alcancar os

seus objectivos estrategicos atraves da governacao e gestao dos sistemas de informacao. Tem como

objectivo optimizar o valor de negocio dos sistemas de informacao, mantendo um equilibrio entre os

benefıcios que alcanca, os riscos de negocio e a utilizacao de recursos. Foca-se em cinco prıncipios:

Ir ao encontro das necessidades dos stakeholders, cobrir toda a organizacao, aplicar uma framework

unica e perfeitamente integrada, permitir uma abordagem holıstica e separar a governacao da gestao.

Tendo em conta o ultimo principio, o COBIT defende que existe uma clara distincao entre governacao

e gestao, na medida em que consistem em diferentes tipos de actividades a realizar, estruturas or-

ganizacionais a considerar e possuem diferentes propositos. A governacao garante que as necessi-

dades dos stakeholders sao avaliadas e analisadas de forma a tomar decisoes ponderadas em termos

dos objectivos da organizacao. E responsavel pela orientacao estrategica da organizacao atraves da

prioritizacao e tomada de decisoes, bem pelo controlo da performance e monitorizacao dos objectivos a

alcancar. Por outro lado, a gestao e responsavel pelo planeamento, execucao e controlo de actividades

de acordo com a governacao de forma a alcancar os objectivos da organizacao.

Sao ainda definidos sete elementos facilitadores, que individualmente ou colectivamente, actuam

como elementos que positiva ou negativamente influenciam a governacao. Estes facilitadores, apre-

sentados na figura 2.5, relacionam-se entre si em termos da sua importancia e da sua presenca na

organizacao. Cada um destes elementos possui um conjunto de stakeholders, objectivos, ciclo de vida,

e um conjunto de boas praticas passıveis de serem definidas.

Figura 2.5: Elementos facilitadores da governacao identificados pelo COBIT. Extraıdo de [3].

Em termos do modelo de referencia de processos, apresentado em detalhe em [4], existem dois

grandes domınios de processos, os processos de governacao e os processos de gestao. O domınio da

governacao contem apenas um sub-domınio, denominado Evaluate, Direct and Monitor (EDO), focado

na governacao da organizacao em termos de alcance dos objectivos, optimizacao do risco e recursos e

transparencia com os stakeholders. Relativamente aos domınio dos processos de gestao, sao definidos

quatro sub-domınios:

• Align, Plan and Organise (APO) - Coordena a gestao de projectos, portfolios e operacoes com

17

a governacao da organizacao em termos de recursos, orcamento, nıveis de servico, qualidade,

risco e seguranca, entre outros aspectos.

• Build, Acquire and Implement (BAI) - Processos necessarios ao desenho, acquisicao e implementacao

de solucoes, tanto a nıvel de planeamento como de execucao, incluindo aspectos como gestao

de configuracoes, gestao de alteracoes, gestao de capacidade e disponibilidade, entre outros.

• Deliver, Service and Support (DSS) - Processos para a entrega e suporte de solucoes desen-

volvidas, desde a gestao de problemas, gestao de incidentes, operacoes ou a simples garantia de

continuidade de produtos e servicos.

• Monitor, Evaluate and Assess (MEA) - Processos para a monitorizacao e avaliacao da perfor-

mance da organizacao, do cumprimento dos requisitos e da conformidade com os processos da

organizacao.

O COBIT, embora garanta a cobertura de um vasto conjunto de processos na governacao e gestao

dos sistemas de informacao, possui uma orientacao muito clara a objectivos de controlo e implementacao

da framework, apresentando inclusive a definicao de responsabilidades em cada uma das actividades a

realizar em cada processo. Por essa razao, nao constitui uma das referencias principais, embora possua

uma vasta base de conhecimento, nomeadamente na area da entrega de solucoes e de orientacao aos

objectivos da organizacao, areas que ainda nao se encontravam devidamente cobertas pelas restantes

referencias.

2.5.2 ITIL v3

Inicialmente desenvolvido por um departamento do governo britanico nos anos 80, o ITIL (Informa-

tion Technology Infrastructure Library ) define um conjunto de processos para a gestao de servicos de

tecnologias de informacao. Tornou-se na principal referencia na gestao de servicos, conhecendo-se

implementacoes das praticas que identifica de acordo com os objectivos individuais de organizacoes

publicas e privadas. As praticas de gestao de servicos sao definidas num conjunto de volumes de

acordo com o ciclo de vida considerado para estes servicos. Ao todo sao 5 volumes que partilham a

mesma estrutura conceptual, apresentando praticas fundamentais e princıpios, processos e actividades

do ciclo de vida, estruturas e papeis na organizacao, consideracoes tecnologicas, desafios e praticas

de implementacao, riscos e factores de sucesso:

• Estrategia de servico - Guias para a obtencao de mais-valias estrategias atraves da melhoria

das capacidades de gestao de servico actuais. Apresenta princıpios que sao importantes no

desenvolvimento e implementacao de polıticas e processos para a gestao de servicos. Define os

processos de gestao financeira, gestao de portfolio de servicos e gestao da procura.

• Desenho de servico - Guias para o desenho e desenvolvimento de servicos e praticas orien-

tadas a sua gestao. Cobre princıpios de desenho e metodos para tornar objectivos estrategicos

da organizacao em portfolios de servicos que garantam um conjunto de mais-valias. Define os

18

processos de gestao de catalogo de servicos, gestao de nıvel de servicos, gestao de capacidade,

gestao de disponibilidade, gestao de continuidade de servico, gestao de seguranca de informacao,

gestao de oferta, gestao de aplicacoes, gestao de Informacao e gestao de servicos de negocio.

• Transicao de servico - Guias para a implementacao e melhoria de processos de transicao de

servicos em desenvolvimento ou manutencao para execucao. Define os processos de gestao de

alteracoes, gestao de configuracoes, gestao de instalacao, gestao de conhecimento, gestao de

stakeholders, planeamento da transicao e avaliacao de servico.

• Operacao de servico - Guias de praticas e actividades necessarias na operacao diaria dos

servicos em execucao. Tem como objectivo garantir a eficiencia e eficacia no suporte de servicos,

garantindo a criacao de valor para o cliente e para a organizacao. Define os processos de gestao

de eventos, gestao de incidentes, gestao de problemas, gestao de pedidos e gestao de acessos.

• Melhoria contınua do servico - Guias para a criacao e manutencao do valor para os clientes

atraves da melhoria dos processos de desenho, transicao e operacao de servicos. Inclui proces-

sos de gestao de nıveis de servico e processos de melhoria.

O ITIL V3 fornece uma visao bastante operacional na gestao de servicos, apresentando praticas

concretas a considerar durante o seu ciclo de vida. Apresenta um foco mais operacional para a gestao

de servicos, estando ligado a tematica da gestao de projectos na medida em que estes podem conduzir

a implementacao de servicos, havendo a necessidade de considerar aspectos do ciclo de vida destes

servicos no processo de gestao de projectos.

2.5.3 ISO 31000 - Risk Management - Principles and Guidelines

A ISO 31000 corresponde a um conjunto de normas internacionais orientadas a gestao de risco nas

organizacoes, fornecendo um conjunto de principios genericos aplicaveis a qualquer organizacao pub-

lica, privada ou comunitaria, nao sendo especıfica a nenhuma industria ou sector.

A gestao de risco e uma das areas mais complexas na gestao de projectos, estando directamente

relacionada com todo o ciclo de vida do projecto, e requer um controlo e avaliacao constantes atraves

de diferentes abordagens. A ISO 31000 surge como uma tentativa de normalizar todo o processo de

gestao de risco, tentando integra-lo na organizacao atraves de uma framework de gestao de risco,

aplicavel tanto a nıvel de gestao de projectos como a todos os nıveis de gestao da organizacao.

Esta norma define o risco como o conjunto de factores e influencias internas ou externas que tornam

incerto o alcance dos objectivos da organizacao. Todas as actividades realizadas envolvem risco, tendo

as organizacoes que identifica-lo, analisa-lo e trata-lo de acordo com um conjunto de medidas. Durante

este processo, e necessario executar actividades de comunicacao do risco a stakeholders bem como

monitorizar e rever o tratamento dos riscos de forma a assegurar que nao sao necessarias novas

medidas a aplicar.

A ISO 31000 define a gestao de risco como a coordenacao de actividades de orientacao e controlo

na organizacao relativamente ao risco, apresentando tambem uma framework de gestao de risco que

19

integra os processos de gestao de risco na governacao da organizacao, em aspectos estrategicos, de

planeamento, comunicacao e culturais. Procura ainda alinha-la com um conjunto de princıpios de forma

a ser eficaz, dos quais se destacam:

• A gestao de risco cria e protege o valor da organizacao, sendo parte integrante dos seus proces-

sos;

• A gestao de risco e parte da tomada de decisoes, sendo estruturada, sistematica e baseada na

informacao mais precisa disponıvel;

• A gestao de risco e adaptada a organizacao, sendo dinamica na melhoria continua da organizacao

e dos seus processos;

• A gestao de risco e transparente e envolve toda a organizacao, tendo sempre aspectos humanos

e culturais em conta.

Na figura 2.6 podemos observar a framework proposta pela ISO 31000, utilizada para a implementacao

da gestao de risco nos processos de gestao da organizacao. Esta framework corresponde a uma

implementacao iterativa e dinamica que, de acordo com aspectos de governacao da organizacao, sera

iterativamente desenhada, implementada, revista e melhorada de forma a permanecer alinhada com os

objectivos da organizacao em termos da gestao de risco.

Figura 2.6: Framework de gestao de risco proposta pela ISO 31000. Extraıdo de [5].

Relativamente a fase de implementacao da gestao de risco, esta considera a implementacao dos

processos de gestao de risco identificados na figura 2.7. A definicao do contexto da gestao de risco,

a avaliacao do risco e o seu tratamento correspondem aos principais processos considerados nesta

norma, que se relacionam directamente com os processos de monitorizacao e revisao bem como de

comunicacao, que fornecem aos restantes processos toda a informacao e feedback necessario para

garantir a sua eficacia.

Destaca-se a importancia dos processos de avaliacao (identificacao, analise e avaliacao) e trata-

mento de risco que constituem o nucleo da gestao de risco na organizacao. Os processos de monitorizacao

e controlo bem como os de comunicacao deverao ser analisados tendo em conta os processos de con-

trolo e de comunicacao do projecto, de forma a serem consistentes com estes. Todos os processos de

20

Figura 2.7: Processos de gestao de risco identificados pela ISO 31000. Extraıdo de [5].

gestao de risco apresentados devem ser analisados no contexto da gestao de risco apresentada pelo

conjunto de referencias anteriores, tendo em conta que todas abordam esta tematica, sendo necessario

avaliar quais os aspectos diferenciadores de cada abordagem e quais se enquadram melhor nos objec-

tivos a alcancar.

21

Capıtulo 3

Analise do Problema

Neste capıtulo o problema e analisado em termos do seu contexto e dos constrangimentos que apre-

senta, de forma a ir ao encontro de uma solucao adequada ao mesmo e aos objectivos a alcancar.

Na seccao de definicao geral do problema sao definidos os principais constrangimentos apresen-

tados pelo problema, directamente ligados ao contexto em que actuam o conjunto de organizacoes

consideradas para aplicacao da solucao. Na seccao de motivacao e contexto pratico do problema e

apresentado o caso real da organizacao considerado, que representa uma especializacao do problema

e que introduz um conjunto de constragimentos a versao da arquitectura aplicada ao caso real.

Na seccao de definicao concreta do problema sao apresentados todos os constrangimentos consid-

erados para o problema e para a solucao a desenvolver, que resultam de toda a analise do problema e

que sao aplicaveis as duas versoes da arquitectura.

3.1 Contextualizacao do Problema

Um pedido de execucao de projecto ou manutencao, apresentado a direccao dos sistemas de informacao

de uma organizacao, necessita de ser classificado em projecto ou manutencao, de acordo com aspec-

tos intrınsecos a cada organizacao na forma como distingue estes dois tipos de pedidos. A ISO 21500

define um projecto como um conjunto unico de actividades coordenadas e controladas com uma data

de inıcio e fim definidas, executadas de forma a alcancar os objectivos do projecto. Relativamente as

manutencoes, a ISO/IEC 14764 identifica uma manutencao como uma modificacao apos a entrega da

solucao, de forma a corrigir falhas da mesma. Esta norma divide os pedidos de manutencao em dois

tipos: correctivos e de melhoria, estes ultimos que passaremos a designar de evolutivos.

Esta analise e consequente classificacao do pedido dependera de um conjunto de factores. As-

pectos como o risco para o negocio, o impacto financeiro para a organizacao ou os nıveis de esforco

necessario para implementacao poderao influenciar esta classificacao. Nao havendo um criterio definido,

tudo depende dos aspectos que a organizacao define como diferenciadores destes tipos de oportu-

nidade.

Depois de considerada viavel pela organizacao, a oportunidade deve ser gerida durante todo o seu

22

ciclo de vida ate a sua aceitacao final, nos moldes definidos pela organizacao. Esta gestao implica toda

a analise e planeamento da oportunidade, implementacao da solucao e aceitacao final da mesma de

acordo com os criterios definidos.

Uma das particularidades do problema abordado e considerar-se que a organizacao nao tem capaci-

dade para realizar a implementacao de projectos internamente, sendo esta implementacao realizada

em outsourcing. Este aspecto tem um impacto elevado em todo o desenho da solucao, tendo em

conta que ira definir constragimentos a forma como o projecto e planeado pela direccao de sistemas de

informacao. Tera de ser tido em conta todo o processo de compra da implementacao do projecto, desde

a escolha do parceiro (entidade responsavel pela implementacao do projecto), o controlo do progresso

de implementacao ou mesmo questoes orcamentais e de calendario.

Apesar da implementacao ser feita em outsourcing, terao de ser considerados processos tanto

de planeamento como de controlo, que serao diferentes dos do parceiro, embora contando com a

colaboracao do mesmo. Outro aspecto importante e o facto das implementacoes das manutencoes

tambem poderem ser realizadas em outsourcing, bem como internamente. Neste caso sera uma de-

cisao tomada pela direccao dos sistemas de informacao tendo em conta aspectos como a capacidade

das equipas ou os recursos disponıveis.

Considera-se tambem que todos os pedidos que chegam a direccao de sistemas de informacao

da organizacao sao internos, ou seja, provenientes de areas de negocio da propria organizacao. Este

aspecto tem particular importancia no que diz respeito a aspectos de facturacao e pagamentos do pro-

jecto ou manutencao, que nao serao considerados pelo facto de se tratarem de oportunidades internas

a propria organizacao.

Tendo em conta o ambito alargado do problema, depois da classficacao da oportunidade em pro-

jecto ou manutencao, o problema sera confinado ao processo aplicado a pedidos classificados como

projectos, garantindo que os pedidos de manutencao sao implementados pela organizacao de acordo

com um processo definido ou integrados num servico de manutencao que e realizado em outsourcing.

Pretende-se tambem desenvolver uma solucao a um nıvel de granularidade mais baixo, nao de-

talhando questoes operacionais e de granularidade fina, deixando uma margem de liberdade para

uma implementacao por parte de organizacoes especıficas. Isto e, nao se pretende que o processo

estabeleca de forma fechada um conjunto de tecnicas para executar determinada actividade, confi-

nando a solucao a descricao das actividades a executar e a forma como estas devem ser coordenadas

entre si.

3.2 Motivacao e Contexto Pratico do Problema

O objectivo de considerar um caso real de uma organizacao e o de definir o processo para a gestao de

pedidos de projectos e manutencoes a partir de um contexto real, utilizando entrevistas e sessoes de

esclarecimento para numa primeira fase compreender o processo actual as-is e de forma incremental

desenhar um novo processo de acordo com o conjunto de referencias analisadas no capıtulo 2.

O desenho do processo sera revisto em conjunto com os stakeholders considerados, de forma a ir

23

de encontro com as suas expectativas, sendo tambem a definicao de responsabilidades e documentos

de suporte de acordo com o feedback obtido em reunioes de revisao e entrevistas. Depois de toda

a arquitectura desenhada para o caso real da organizacao, o objectivo sera generaliza-la de forma a

ser aplicavel a um conjunto de outras direccoes de sistemas de informacao, que embora estabelecidas

noutros contextos reais, possam adoptar este processo para a gestao deste tipo de pedidos, tendo

apenas como pressupostos os contragimentos definidos na seccao de contextualizacao do problema.

A direccao de sistemas de informacao encontra-se organizada de acordo com o organograma ap-

resentado na figura 3.1. A entidade maxima corresponde a administracao da direccao de sistemas de

informacao, responsavel por toda a gestao estrategica e por questoes orcamentais, nomeadamente

a aprovacao de orcamentos da direccao de sistemas de informacao. O director DSI corresponde a

entidade que regula as areas de projectos e de manutencoes, sendo o responsavel maximo por es-

tas duas areas, tendo tambem a responsabilidade da gestao de portfolios. A area de planeamento e

controlo (P&C) e responsavel pela gestao operacional de orcamento, realizando alteracoes e revisoes

aos orcamentos de projectos. A area de compras e a area responsavel por conduzir os processos de

compra de implementacoes de projectos e manutencoes, desde a consulta ao mercado a definicao das

minutas de contractos e notas de encomenda. As areas de projectos e manutencao (O&M) sao as

responsaveis pela execucao de projectos e manutencoes, subdividindo-se em equipas de projectos e

equipas de manutencao, cada uma delas tendo um gestor de projecto ou um gestor de manutencao,

respectivamente.

Figura 3.1: Estrutura da organizacao considerada como caso real.

A area de projectos ira comprar a implementacao a terceiros, em outsourcing, embora mantenha

processos de planeamento e controlo do projecto, distintos do parceiro. As implementacoes de manutencoes

poderao ser realizadas internamente ou compradas em regime de outsourcing, ficando a cargo desta

area a decisao, com a aprovacao do director DSI. Relativamente aos pedidos de manutencao, estes

pedidos serao confinados a pedidos de manutencao evolutiva, considerando que a organizacao dispoe

de um servico de Help-Desk de primeira linha que filtra os pedidos que chegam a direccao de sistemas

de informacao.

Relativamente a classificacoes de pedidos entre pedidos de execucao de projectos e de manutencoes

24

evolutivas, a direccao de sistemas de informacao possui um criterio estabelecido que define que a

classificacao e realizada de acordo com um criterio de esforco. Pedidos classificados com um esforco

superior a 5 dias (esforco/homem), constituem pedidos de execucao de projectos enquanto os restantes

contituem pedidos de manutencoes evolutivas.

Todo o processo de compra de implementacoes, quer de projectos quer de manutencoes, e realizado

pela area de compras, que pode ser aconselhada pelas areas de projectos e de manutencoes, tendo

como responsabilidade conduzir todo o processo. E responsavel por seleccionar parceiros de acordo

com um conjunto de criterios de avaliacao, receber propostas, seleccionar a proposta a adjudicar e

definir minutas de contracto e notas de encomenda.

Um projecto so entra em ambiente de producao, que corresponde ao estado final do projecto ja em

funcionamento no ambiente final, apos aprovacao da area de manutencao. Esta aprovacao e feita com

a aceitacao do projecto pela area de manutencao e, apos a passagem a producao, passa a ser sua

responsabilidade. Futuros pedidos de correccao serao enderecados a esta area, que devera possuir

todas as ferramentas e conhecimento necessarios para proceder ao seu tratamento.

3.3 Definicao Concreta do Problema

Considerando este problema, e necessario identificar, tendo em conta um conjunto de referencias na

area de gestao de projectos e manutencoes, quais os processos necessarios definir e de que forma

estes deverao ser coordenados durante todo o ciclo de vida do pedido. Para definir estes processos sera

necessario analisar o conjunto de referencias apresentadas no capıtulo 2 e de seguida identificar um

conjunto de processos a considerar, tendo em conta que a gestao de projectos possui um domınio de

grande dimensao e impossıvel de cobrir na sua totalidade tendo em conta o tempo de desenvolvimento

disponıvel.

Por esta razao, uma das referencias analisadas foi a ISO/IEC 12207, que identifica todos os proces-

sos do ciclo de vida do software e servicos. Importa destacar que a escolha destas areas de processos

foi feita de acordo com um conjunto de entrevistas a stakeholders realizadas durante a definicao dos

objectivos da solucao, resultando num conjunto escolhido de acordo com o feedback recebido de profis-

sionais na area e orientado ao problema que estamos a considerar.

Relativamente a divisao apresentada nesta referencia entre processos no contexto do sistema e

processos no contexto do software, vamos considerar apenas processos do contexto do sistema, na

medida em que nao pretendemos detalhar aspectos operacionais da gestao de projecto, que serao

intrınsecos e correspondentes as praticas especıficas de cada organizacao. Esta decisao procura

tambem deixar espaco de liberdade para a implementacao dos processos por parte da organizacao,

nao a restringindo a decisoes tomadas de acordo com um arquitectura que se procura o mais general-

izada possıvel.

Considerando os processos do contexto do sistema, nao serao considerados os processos tecnicos,

que sao definidos por esta norma internacional como os processos necessarios a definicao de uma

solucao de acordo com requisitos especıficos de um produto de software ou servico. Nao pretendemos

25

uma arquitectura orientada ao desenvolvimento das solucoes mas sim a gestao de projectos, a partir

dos quais estas serao desenvolvidas.

Os processos de projecto serao aqueles que irao ter um maior foco no desenho da arquitectura, na

medida em que identifica processos intimamente ligados a gestao de projecto. Esta referencia consid-

era como processos primarios os processos de planeamento e de controlo de projecto, os quais iremos

tambem considerar para a arquitectura a desenvolver. Directamente relacionados, iremos tambem con-

siderar o processo de gestao de risco e o processo de gestao de decisao. Todos os restantes processos

identificados no contexto dos processos de projecto nao serao considerados por se tratarem de pro-

cessos mais operacionais, como por exemplo a gestao de configuracoes, que deverao ser analisados

numa perspectiva mais orientada a organizacao em si e as solucoes a desenvolver.

Tendo em conta que estamos a considerar a compra das implementacoes de projectos e manutencoes

em outsourcing, sera tambem considerado o processo de aquisicao, na medida em que determina um

conjunto de actividades a realizar para o planeamento e execucao de uma compra de software ou

servico. O processo de fornecimento sera tambem considerado, embora tenha de ser adaptado tendo

em conta que estamos a considerar apenas pedidos internos a organizacao, o que tera influencia num

conjunto de aspectos do processo como a definicao de contractos.

Relativamente aos processos de projecto e de compra, a ISO 21500 e o PMBOK, consideradas

como as pricipais referencias na gestao de projecto, identificam um conjunto de processos, permitindo-

nos seleccionar aqueles a considerar no desenho da arquitectura. Assim, iremos considerar os seguintes

processos relativos aos processos de projecto e de compra da ISO/IEC 12207:

Processos de gestao de projectos Processos

Integracao

- Inıcio do projecto;- Desenvolvimento de planos de projecto;- Monitorizacao e controlo de actividades de projecto;- Controlo de alteracoes;- Encerramento do projecto;- Identificacao de licoes aprendidas;

Stakeholders - Identificacao de stakeholders;- Controlo de stakeholders;

Calendario - Definicao do calendario de projecto;- Controlo do calendario de projecto;

Custos- Identificacao de custos de projecto;- Definicao do orcamento de projecto;- Controlo de custos de projecto;

Riscos

- Identificacao de riscos;- Avaliacao de riscos;- Tratamento de riscos;- Controlo de riscos;

Compras- Planeamento da compra;- Seleccao de parceiros;- Controlo da compra;

Comunicacao- Planeamento das comunicacoes;- Distribuicao da informacao;- Controlo da comunicacao;

Tabela 3.1: Processos de projecto e de compra considerados para o desenho da arquitectura.

Importa destacar que nao serao detalhadas as areas de gestao de ambito e gestao de recursos iden-

tificadas por estas referencias, pois alem de serem areas complexas que nao poderiam ser abordadas

com a necessaria extensibilidade, correspondem a processos directamente ligados a organizacao que

os implementa e ao tipo de projectos que executa, sendo utilizados processos e metodos especıficos e

26

adaptados a contextos especificos de actuacao.

Um processo de gestao de projecto que nao e identificado por nenhuma das referencias e a gestao

de issues. Um issue e definido como um acontecimento que ocorreu e nao foi planeado, sendo

necessario proceder a sua gestao. Pode ser gerado por um risco que tenha ocorrido ou qualquer

tipo de nao-conformidade com planos ou requisitos do projecto. O ITIL apresenta um conjunto de pro-

cessos passıveis de serem adoptados para a gestao de issues, nomeadamente a gestao de problemas

e gestao de incidentes, que serao utilizados para a definicao do processo.

Relativamente aos processos organizacionais, serao considerados apenas os processos de gestao

de portfolio pois consideramos que as oportunidades de projecto e de manutencao sao integradas em

portfolios, sendo estes sujeitos a um processo de gestao de orcamento e calendario com impacto no

planeamento de todos os projectos que deles fazem parte. Apesar de nao ser o foco desta solucao,

decidimos incluir os processos de gestao de portfolio no ambito da arquitectura de processos, embora

sem um detalhe aprofundado.

Os processos de gestao de portfolio e de fornecimento definidos pela ISO/IEC 12207 nao sao de-

talhados pela ISO 21500 e pelo PMBOK, razao pela qual serao consideradas as areas de Align, Plan

and Organise (APO), de Build, Acquire and Implement (BAI) e de Deliver, Service and Support (DSS)

apresentadas pelo COBIT para enderecar estes processos. Sera tambem considerado o caso real da

organizacao como input para a definicao destes processos embora tenha de ser tido em conta que a

gestao de portfolio encontra-se, na maioria das organizacoes, definida de acordo com os seus proprios

objectivos e visao de mercado.

Os processos de fornecimento que iremos considerar correspondem a aceitacao da solucao pro-

duzida, a passagem do projecto para a area de manutencao, a qual sera a responsavel pelo mesmo

a partir do momento da entrega, a passagem de ambiente de qualidade para ambiente de producao

e o encerramento do projecto. Um processo muitas vezes associado ao encerramento do projecto e a

formacao dos utilizadores, que sendo um processo intrınseco ao projecto e as suas caracterısticas, nao

sera considerado na arquitectura.

A recepcao e classificacao de pedidos de projectos e manutencoes nao se encontra directamente

coberta pelas referencias, pelo que sera necessario algum desenvolvimento original com base no caso

real da organizacao. E importante ainda destacar que esta classificacao e intrınseca a organizacao, nao

existindo processos bem definidos para este conjunto de actividades. Encontra-se tambem relacionada

com a governacao da organizacao, que define os conceitos de projectos e manutencoes de acordo

com o seu posicionamento estrategico no mercado e objectivos de negocio. Considera-se assim que

cada organizacao possui um criterio para a classificacao de projectos e manutencoes, sendo esta

classificacao de complexidade variavel de acordo com a organizacao.

Em termos de pedidos de manutencao, considera-se que depois de classificados, sao integrados

em portfolios de servicos de manutencao, que correspondem a servicos comprados em outsourcing, ou

agendados para manutencao. Tendo esta decisao em conta, os processos de gestao da manutencao

serao confinados aos processos de planeamento da manutencao identificados pela ISO/IEC 14764.

27

Capıtulo 4

Solucao

Neste capıtulo e apresentada a solucao proposta para o problema da gestao de pedidos de projectos e

manutencoes, detalhando-se as tres vistas definidas para esta arquitectura: Vista de processos, vista

de responsabilidades e vista de informacao.

Os principais concerns dos stakeholders na gestao de projectos e manutencoes sao assim enderecados

atraves da vista de processos, que identifica o conjunto de actividades a realizar e de que forma de-

vem ser coordenadas, da vista de responsabilidades, que identifica os intervenientes e respectivas

responsabilidades nas actividades definidas e da vista de informacao, que apresenta um conjunto de

documentos de suporte as actividades definidas na vista de processos.

A apresentacao da arquitectura encontra-se dividida em quatro fases conceptuais, directamente

ligadas ao ciclo de vida dos projectos e manutencoes considerado e ao problema enderecado. Cada

fase e identificada por um inıcio e fim bem definidos, correspondendo a pontos estrategicos na gestao

dos projectos e manutencoes na organizacao.

4.1 Arquitectura de Processos

A norma ISO/IEC 42010: Systems and Software Engineering – Architecture Description [9], descreve os

conceitos que devem ser considerados quando se desenvolvem arquitecturas conceptuais de sistemas,

considerando o contexto e os objetivos que se pretendem atingir. De acordo com esta norma, uma

arquitectura corresponde aos principais conceitos e propriedades de um sistema de acordo com o

contexto em que este existe, englobando o conjunto dos seus elementos e relacoes.

Considerando o modelo conceptual apresentado na figura 4.1 e descrito nesta norma, pretende-se

desenvolver uma architecture framework, que identifica um sistema de interesse atraves de um ou mais

concerns do mesmo. Esta framework e definida por viewpoints que coordenam os comportamentos,

responsabilidades e estruturas de informacao na organizacao.

Tendo em conta este modelo conceptual, define-se como sistema de interesse a gestao de projectos

e manutencoes na organizacao, que e enderecada pela arquitectura de processos definida. A direccao

dos sistemas de informacao e a administracao da organizacao, que sao os principais stakeholders,

28

Figura 4.1: Modelo conceptual da arquitectura de processos. Extraıdo de [9].

apresentam um conjunto de concerns associados a este sistema, directamente relacionados com o

conjunto de questoes apresentado na seccao 1.2 de definicao do problema:

• Que processos (e correspondentes actividades) devem ser executados para a gestao de pedidos

de projectos e manutencoes que chegam a direccao dos sistemas de informacao?

• Quais as responsabilidades dos varios elementos da direccao de sistemas de informacao em

todas as actividades de gestao de pedidos de projectos e manutencoes?

• Quais os documentos que suportam todas as actividades realizadas na gestao de projectos e

manutencoes?

4.1.1 Vista de Processos

Um processo de negocio corresponde a um conjunto de actividades e tarefas relacionadas entre si e

coordenadas de forma a alcancar determinados objectivos de negocio. No caso da arquitectura de

processos a desenvolver, pretende-se definir um conjunto de actividades, de acordo com as melhores

praticas identificadas no capıtulo 2, e coordena-las de modo a gerir pedidos de projectos e manutencoes

que chegam a direccao de sistemas de informacao.

Para definir o fluxo de todo o processo de gestao de pedidos de projectos e manutencoes sera

utilizada a linguagem BPMN (Business Process Model and Notation) 2.0. Esta linguagem fornece uma

representacao grafica para a especificacao de processos de negocio, conhecendo uma grande adopcao

por parte de organizacoes em todo o mundo para a definicao dos seus processos, sendo por essa razao

a linguagem de modelacao escolhida para a definicao desta vista.

Tendo em conta que o fluxo do processo e apresentado em termos de macro-actividades, sao ainda

apresentadas um conjunto de actividades detalhadas referentes a cada macro-actividade. A definicao

de cada actividade detalhada foi baseada nas referencias analisadas no capıtulo 2, cujos processos de

29

gestao apresentavam um conjunto de actividades e objectivos a cumprir, a partir dos quais foi feita a

adaptacao para os objectivos especıficos desta arquitectura.

Na figura 4.2 e apresentado o fluxo completo do processo de gestao de projectos e manutencoes

desenvolvido. O processo foi dividido em quatro fases, de acordo com a vista de processos apresen-

tada. Assume-se que uma fase do processo possui um inıcio e fim bem definidos, sendo nestes pontos

alcancados objectivos estrategicos da organizacao. As fases de oportunidade, de planeamento, de

implementacao e controlo e de handover constituem todo o ciclo de vida do pedido de projecto desde

que e recebido pela direccao dos sistemas de informacao, vindo da area de negocio, ate a entrega

e encerramento do projecto. Os pedidos que sejam classificados como manutencoes, apos a fase

de oportunidade, sao integrados em portfolios de servicos de manutencao ou sao agendados para

implementacao.

Figura 4.2: Fluxo completo do processo de gestao de projectos e manutencoes.

4.1.2 Vista de Responsabilidades

Na vista de responsabilidades sao atribuıdas, para cada uma das actividades detalhadas definidas

na vista de processos, um conjunto de responsabilidades aos elementos da direccao de sistemas de

informacao. Para a definicao desta vista foi considerada a estrutura organizacional da direccao de

sistemas de informacao do caso real considerado. Para cada actividade, os intervenientes do processo

possuem um conjunto de responsabilidades de acordo com o seu papel na organizacao e com as

actividades que devem executar.

A vista de responsabilidades e traduzida, por cada fase, numa matriz de responsabilidades, que

relaciona actividades a executar e intervenientes do processo atraves de um conjunto de responsabili-

dades definido de acordo com um modelo de responsabilidades. O modelo mais comum de definicao de

responsabilidades e o modelo RACI (Responsible, accountable, Consulted and Informed), que define

as seguintes responsabilidades:

30

• Responsible - Elemento com a responsabilidade de executar a actividade, havendo no mınimo

um elemento com esta responsabilidade.

• Accountable - Elemento com autoridade na execucao da actividade, sendo o principal responsavel

pela sua concretizacao e o qual delega a responsabilidade de execucao da actividade.

• Consulted - Elemento cujas opinioes e conhecimentos sao tidos em conta na execucao da ac-

tividade, e com o qual existe comunicacao bilateral.

• Informed - Elemento que deve ser informado do progresso da actividade, correspondendo a uma

comunicacao unilateral.

Apesar deste modelo ser amplamente adoptado pelas organizacoes, decidiu-se considerar um mod-

elo extendido, o qual designamos por matriz de responsabilidades e que foi proposto por Grude e Haug

[1], que apresenta a seguinte definicao de responsabilidades:

• X - Elemento responsavel por executar as tarefas a realizar na actividade.

• D - Elemento com poder de decisao individual e final num ponto de decisao do processo.

• d - Elemento com poder de decisao em conjunto, podendo influenciar a decisao tomada por um

elemento com uma responsabilidade de decisao individual.

• P - Elemento responsavel por assegurar que as actividades sao planeadas, implementadas e

controladas. Muitas vezes esta responsabilidade e delegada tambem a outros elementos mais

proximos dos responsaveis pela execucao das actividades.

• C - Elemento que deve ser consultado, possuindo informacoes que devem ser tidas em conta

no controlo de progresso, execucao de actividades e tomadas de decisao. Apesar de haver uma

obrigatoriedade de consulta, este elemento nao possui qualquer responsabilidade de decisao,

podendo a sua opiniao ser ignorada.

• A - Elemento a consultar opcionalmente, podendo possuir informacoes e opinioes numa fase do

projecto cuja importancia so pode ser avaliada nessa mesma fase.

• I - Elemento que deve ser informado da execucao, decisao ou controlo da actividade, correspon-

dendo a uma comunicacao unilateral.

A adopcao deste modelo na arquitectura de processos tem em vista a definicao de uma vista de

responsabilidades detalhada face a apresentada pela RACI, apresentando uma maior extensao no que

diz respeito a definicao de responsabilidades de decisao e de trocas de informacao.

A definicao da vista de responsabilidades, em contraste com a vista de processos, foi desenvolvida

atraves de trabalho original, nao sendo apresentada nenhuma proposta no conjunto das referencias

analisadas no capıtulo 2. Assim, foi necessario analisar a estrutura organizacional da direccao dos

sistemas de informacao, compreender quais os principais elementos e responsabilidades actuais e, de

acordo com a vista de processos definida, atribuir um conjunto de responsabilidades aos elementos

nas actividades identificadas.

31

4.1.3 Vista de Informacao

A vista de informacao define um conjunto de documentos de suporte ao processo de gestao de pro-

jectos e manutencoes. Esta vista relaciona-se com as anteriores na medida em que apresenta um

conjunto de documentos produzidos e consumidos pelas actividades definidas na vista de processos,

que sao utilizados pelos intervenientes no processo, identificados na vista de responsabilidades.

O objectivo desta vista e identificar o conjunto de documentos de suporte ao processo, descrevendo

a informacao contida e os respectivos objectivos. Estes documentos foram propostos tendo em conta

as referencias analisadas e um conjunto de necessidades especıficas relacionadas com o caso real

considerado. Este conjunto de documentos encontra-se adaptado a arquitectura desenvolvida, podendo

ser extendido ou adaptado numa implementacao desta arquitectura.

Alem desta descricao, pretende-se ainda apresentar de que forma os elementos da direccao dos

sistemas de informacao interagem com estes documentos, apresentando quais as entidades que criam,

consultam e alteram os varios documentos ao longo do processo. Por essa razao, considerou-se o

conceito de matriz de interaccoes, ou matriz CRUD (Create, Read, Update and Delete), amplamente

utilizado na definicao de arquitecturas de informacao nos sistemas de informacao, nas quais estas

matrizes sao usadas para descrever um conjunto de interaccoes de criacao, leitura, escrita e remocao

de informacao entre intervenientes e fontes de infomacao. Este conceito foi inspirador para a definicao

desta vista de informacao, levando a definicao do conceito de matriz CRUF:

• C - Criacao do documento.

• R - Obrigatoriedade de consulta do documento, embora a ausencia desta interaccao nao seja

impeditiva da consulta opcional do mesmo.

• U - Actualizacao ou alteracao do documento.

• F - Fecho do documento, com o arquivamento do mesmo para posterior consulta.

Assim, para cada fase do processo definida nesta arquitectura, e apresentada uma matriz CRUF que

relaciona os intervenientes com os documentos de suporte correspondentes a essa fase. A adopcao

desta matriz foi considerada durante o desenvolvimento da arquitectura de processos de forma a com-

plementar a vista de informacao e relaciona-la com as duas outras vistas, sendo uma proposta aceite

por todos os stakeholders na medida em que apresenta, de forma inovadora, uma nova visao na

definicao de interaccoes com o conjunto de documentos de suporte do processo.

4.2 Fase de Oportunidade

Na fase de oportunidade e feita a identificacao e respectiva classificacao do pedido recebido em opor-

tunidade de projecto ou de manutencao, podendo esta oportunidade ainda ser rejeitada. Caso seja

aceite, e iniciado o planeamento da oportunidade em termos de ambito, orcamento, calendario e analise

32

tecnica. Oportunidades de manutencao que nao tenham sido agendadas para implementacao sao in-

tegradas em portfolio, procedendo-se a uma definicao de orcamento, calendario e prioridade. Na figura

4.3 e apresentado o fluxo do processo relativo a fase de oportunidade.

Figura 4.3: Fluxo do processo relativo a fase de oportunidade.


De acordo com o fluxo do processo apresentado na figura 4.3 o processo inicia-se com a chegada

do pedido a direccao de sistemas de informacao. Todos os pedidos sao recebidos pela area de

projectos, aquela que possui elementos com a capacidade de analise do pedido em termos da sua

classificacao em projecto ou manutencao. Este pedido representa uma necessidade identificada pela

area de negocio e nesta fase do processo, e realizada uma analise a dois nıveis:

• Analise de negocio, a partir da qual e definido o caso de negocio que avalia a oportunidade em

termos de benefıcios para a organizacao.

• Analise de solucao, a partir da qual e definido o statement of work onde sao identificados os

resultados esperados com a aceitacao da oportunidade.

Estas analises serao necessarias na classificacao da oportunidade em projecto ou manutencao, a

qual e estabelecida em termos de uma definicao de esforco na concretizacao da oportunidade (esforco

por elemento de equipa) realizada tendo em conta o statement of work, definido previamente. Tendo

em conta o caso real considerado, uma oportunidade cujo nıvel de esforco para concretizacao e avali-

ado em cinco ou mais dias de trabalho por elemento da equipa, e classificada como projecto. Caso

33

contrario, tratar-se-a de uma oportunidade de manutencao. Na arquitectura definida considera-se que

a classificacao e baseada num criterio de esforco, embora nao impondo nıveis de classificacao.

E tambem realizada uma analise de viabilidade da oportunidade, embora no caso real considerado

uma oportunidade seja apenas rejeitada caso a direccao dos sistemas de informacao nao possua re-

cursos humanos suficientes para a sua aceitacao. Esta questao prende-se com o facto da organizacao

possuir um conjunto de mais-valias associadas ao numero de oportunidades aceites, pelo que tem

interesse em aceitar o maior numero possıvel. Importa tambem destacar que toda as actividades de

identificacao e classificacao da oportundidade sao realizadas em colaboracao entre as areas de pro-

jectos e manutencoes, como sera perceptıvel na vista de responsabilidades. Na tabela 4.1 sao apre-

sentadas as actividades detalhadas referentes as macro-actividades de identificacao e classificacao da

oportunidade.

Actividades

GPM-OP1 – Identificacao da oportunidade – Inıcio da identificacao do pedido com a definicao do caso de negocio edo statement of work.

GPM-OP1.1 – Registo da oportunidade em sistema de tracking.

GPM-OP1.2 – Atribuicao de um responsavel pela qualificacao da oportunidade.

GPM-OP1.3 – Definicao do caso de negocio da oportunidade de acordo com a identificacao apresentada.

GPM-OP1.4 – Definicao do statement of work de acordo com a identificacao da oportunidade realizada.

GPM-OP2 – Classificacao da oportunidade – Atribuicao de uma area ao pedido e responsavel pela sua gestao.

GPM-OP2.1 – Classificacao do pedido como projecto ou manutencao evolutiva com base numa analise de esforco(esforco/homem).

GPM-OP2.2 – Reuniao conjunta de elementos de projectos e de O&M para analise preliminar da viabilidade da oportunidade.

GPM-OP2.3 – Decisao de aceitacao da oportunidade de acordo com a classificacao realizada e a analise de viabilidade daoportunidade.

GPM-OP2.4 – Inıcio da definicao do project charter : responsavel pelo projecto, respectivas responsabilidades e a entidadeque aprova o projecto.

Tabela 4.1: Actividades detalhadas de identificacao e classificacao da oportunidade.

Caso a oportunidade seja classificada como um projecto, e realizada uma analise da oportunidade

em termos de requisitos funcionais, calendario, orcamento, riscos e solucao tecnica. Nesta fase, a area

de projectos pode realizar uma reclassificacao do pedido, caso considere que a oportunidade se trate

de uma manutencao e que a classificacao inicial nao tenha sido a correcta. Da analise da oportunidade

de projecto resulta o project charter, que sera utilizado para obtencao de aprovacao da oportunidade e

para o inıcio do planeamento do projecto.

Apos esta analise, a oportunidade e integrada num portfolio de projectos, que reune o conjunto de

oportunidades de projecto consideradas pela organizacao. Nesta fase, a analise anterior e reavaliada

numa perspectiva do conjunto de projectos que compoem o portfolio, sendo atribuida uma prioridade a

oportunidade, em funcao das restantes que compoem o mesmo, bem como realizada uma reavaliacao

de orcamento e calendario. Este portfolio e gerido pela area de projectos, e sera depois submetido

para avaliacao ao director DSI, que ira considerar o conjunto de portfolios da direccao de sistemas de

informacao e gerir as varias oportunidades de acordo com aspectos de governacao da organizacao.

Na tabela 4.2 sao apresentadas as actividades detalhadas referentes as macro-actividades de analise

34

da oportunidade e de integracao em portfolio.

Actividades

GPM-OP3 – Analise da oportunidade – Primeira abordagem a gestao do pedido com definicao de ambito, stakehold-ers, milestones e estimativa de alto nıvel de orcamento.

GPM-OP3.1 – Identificacao de alto nıvel dos stakeholders do projecto.

GPM-OP3.2 – Definicao dos objectivos, criterios de sucesso, assumpcoes e,constrangimentos de alto nıvel do projecto.

GPM-OP3.3 – Definicao de requisitos funcionais de alto nıvel do projecto baseados no statement of work.

GPM-OP3.4 – Definicao de esboco de solucao de alto nıvel tecnica do projecto de forma a auxiliar no planeamento demilestones e orcamento do projecto.

GPM-OP3.5 – Analise e decisao de reclassificacao do pedido de projecto em pedido de manutencao com base na analisetecnica e de requisitos do projecto.

GPM-OP3.6 – Definicao de milestones de alto nıvel do projecto.

GPM-OP3.7 – Definicao de alto nıvel de estimativa de orcamento do projecto.

GPM-OP3.8 – Identificacao de alto nıvel dos riscos associados ao projecto e a sua aceitacao pela organizacao.

GPM-OP4 – Integracao em portfolio de projectos – Gestao de portfolios de projecto com a definicao de score, cal-endario e orcamento de cada uma das oportunidades que compoem o portfolio.

GPM-OP4.1 – Atribuicao de score do projecto no contexto do portfolio de projectos, definindo a prioridade e importancia desteprojecto face aos restantes que compoem o portfolio.

GPM-OP4.2 – Definicao de estimativa de calendario do projecto no contexto do portfolio de projectos, tendo em conta asmilestones do projecto e os restantes projectos que compoem o portfolio.

GPM-OP4.3 – Definicao de orcamento do projecto no contexto do portfolio de projectos, analisando o orcamento totaldisponıvel para o portfolio e que sera futuramente submetido para aprovacao.

Tabela 4.2: Actividades detalhadas de analise da oportunidade e integracao em portfolio de projectos.

No caso de uma oportunidade classificada como manutencao, e realizada uma analise da oportu-

nidade de forma a identificar os requisitos da manutencao e realizar um esboco da solucao tecnica,

que ira permitir proceder a uma analise de esforco e a uma estimativa dos recursos necessarios e de

orcamento. Nesta macro-actividade e ainda tomada a decisao de compra da manutencao na forma

de servico de manutencao ou de implementacao interna pela area de manutencao. Tendo em conta a

analise de recursos necessarios e a capacidade da area de manutencao, e necessario avaliar se esta

area possui os recursos necessarios para realizar a implementacao e se e a opcao mais benefica para

a organizacao. Caso a area de manutencao conclua que nao possui capacidade para implementar a

manutencao, esta sera integrada num servico de manutencao, realizado em outsourcing e que na maio-

ria dos casos reune uma bolsa de horas, disponıveis para um conjunto de actividades de manutencao.

Caso seja tomada a decisao de implementacao interna, sera realizado o planeamento da manutencao,

com a alocacao de recursos, a definicao de calendario e o agendamento da manutencao no back-

log de operacoes de manutencao da area de manutencao. Apos esta actividade, considera-se que a

organizacao dispoe de um processo para a implementacao do conjunto das manutencoes pertencentes

ao backlog de manutencao.

No caso de integracao num servico de manutencao, e necessario, numa primeira fase, de acordo

com a analise de esforco realizada para a oportunidade, integra-la num servico de manutencao per-

tencente ao portfolio de servicos da organizacao, sendo depois realizada uma revisao da prioridade do

servico e do orcamento no contexto do portfolio de servicos de manutencao. Este portfolio, de forma

paralela ao que acontece com o portfolio de projectos, pertence a area de manutencao.

35

Depois da gestao da oportunidade por parte da area de projectos ou manutencao, de acordo com

a sua classificacao, sera realizada uma analise de portfolio por parte do director DSI, que entre out-

ros aspectos, ira rever questoes de orcamento, calendario e prioridades de projectos e manutencoes

pertencentes aos portfolios da direccao de sistemas de informacao. Esta analise tem como objectivo

a definicao do orcamento anual da direccao de sistemas de informacao, que deve ser submetido para

aprovacao a administracao de forma a garantir que todas as oportunidades consideradas se encontram

aprovadas para o inicio do seu planeamento. Estas actividades nao serao consideradas nesta versao

da arquitectura, embora desenvolvidas no ambito da arquitectura aplicada ao caso real, por serem

especıficas a organizacao e a sua estrutura organizacional.


Os principais intervenientes na fase de oportunidade sao a area de projectos e a area de manutencao,

executando todas as actividades com o auxılio da area de planeamento e controlo em questoes orcamentais,

do director DSI em tomadas de decisao de aceitacao e classificacao da oportunidade e da area de

negocio, responsavel pela apresentacao da oportunidade a direccao de sistemas de informacao.

A identificacao da oportunidade e realizada pela area de projectos, que recebe o pedido e atribui

um responsavel pela qualificacao da oportunidade, em acordo com o director DSI. Nestas actividades,

a area de O&M, o director DSI e a area de negocio desempenham um papel de aconselhamento,

sendo consultadas para actividades como a definicao do statement of work ou do caso de negocio. A

classificacao da oportunidade tambem e realizada na sua totalidade pela area de projectos, em parceria

com a area de O&M, que e consultada durante toda a actividade, e com o director DSI, responsavel pela

decisao final de aceitacao da oportunidade. Na tabela 4.3 e apresentada a matriz de responsabilidades

referente as actividades de identificacao e de classificacao da oportunidade.

Actividades Projectos O&M P&C Director

DSINegocio

GPM-OP1 – Identificacao da oportunidade

GPM-OP1.1 X/P A I

GPM-OP1.2 X/P/d A D I

GPM-OP1.3 X/P I C

GPM-OP1.4 X/P C C

GPM-OP2 – Classificacao da oportunidade

GPM-OP2.1 X/P C

GPM-OP2.2 X/P C I

GPM-OP2.3 X/P/d A D I

GPM-OP2.4 X/P A

Tabela 4.3: Matriz de responsabilidades das actividades de identificacao e analise da oportunidade.

A analise da oportunidade de projecto e realizada na totalidade pela area de projectos, estando a

area de manutencao, a area de planeamento e controlo, o director DSI e a area de negocio disponıveis

para ser consultados e fornecer aconselhamento na analise tecnica, de orcamento, de calendario e de

36

riscos. Ja na integracao em portfolio de projectos, a area de projectos executa todas as actividades em

parceria com o director DSI, que e consultado em todas as actividades, e com a area de planeamento

e controlo, consultada em aspectos orcamentais. Na tabela 4.4 e apresentada a matriz de responsabil-

idades referente as actividades de analise da oportunidade de projecto e de integracao em portfolio de

projectos.


DSINegocio

GPM-OP3 – Analise da Oportunidade

GPM-OP3.1 X/P A C

GPM-OP3.2 X/P C

GPM-OP3.3 X/P C

GPM-OP3.4 X/P A A

GPM-OP3.5 X/P/D A C

GPM-OP3.6 X/P A C

GPM-OP3.7 X/P C A

GPM-OP3.8 X/P A A A A

GPM-OP4 – Integracao em Portfolio de Projectos

GPM-OP4.1 X/P C

GPM-OP4.2 X/P A C

GPM-OP4.3 X/P C C

Tabela 4.4: Matriz de responsabilidades das actividades de analise da oportunidade e integracao emportfolio de projectos.

A analise da oportunidade de manutencao e feita na totalidade pela area de manutencao, sendo

consultada a area de negocio para a definicao de requisitos de manutencao e a area de planeamento

e controlo para a definicao do orcamento. A decisao de implementacao da manutencao interna ou de

compra sob a forma de servico de manutencao e realizada pela area de manutencao e pelo director DSI,

pertencendo a este ultimo a decisao final. Caso a manutencao seja implementada internamente, todas

as actividades sao executadas pela area de manutencao, tendo esta apenas de informar o director DSI

e a area de negocio do agendamento da implementacao da manutencao. No caso da manutencao ser

integrada num servico de manutencao, as actividades sao executadas pela area de manutencao com o

auxılio da area de planeamento e controlo e do director DSI.

As responsabilidades identificadas nesta fase encontram-se intimamamente ligadas a estrutura da

organizacao, que define constrangimentos concretos a recepcao do pedido e a sua classificacao. O

facto da recepcao e classificacao da oportunidade ser feita pela area de projectos define de forma

restrita o conjunto de responsabilidades nestas actividades. O papel da area de manutencao como

entidade a ser consultada nestas actividades foi proposto tendo em conta este constrangimento, de

forma a envolver as duas principais areas que irao gerir posteriormente o projecto ou a manutencao.

Apos a classificacao, a definicao de responsabilidades encontra-se normalizada com a maioria dos

casos reais das organizacoes que possuem areas distintas para lidar com pedidos de projectos e pedi-

dos de manutencoes. Cada uma das areas lida com as suas oportunidades separadamemente, embora

37

com trocas de informacao entre si de forma a partilhar informacoes, resultados e objectivos em comum.


A fase de oportunidade inicia-se com o registo da oportunidade num sistema de tracking de pedidos

na direccao dos sistemas de informacao. Este registo apresenta a primeira definicao da oportunidade

do ponto de vista do negocio, podendo ser complementado por informacao proveniente do elemento

responsavel pela recepcao dos pedidos. O registo da oportunidade fornece informacao que, em con-

junto com o feedback proveniente da area de negocio, permite definir o statement of work e o caso de

negocio.

O caso de negocio e o statement of work sao dois documentos que se complementam no que

diz respeito a caracterizacao da oportunidade. O caso de negocio apresenta a oportunidade em ter-

mos de investimento e oportunidade de negocio, identificando um conjunto de benefıcios esperados e

resultados a alcancar. O statement of work possui um caracter mais orientado aos resultados espera-

dos, identificando os produtos ou servicos pretendidos para colmatar um determinada necessidade de

negocio.

O project charter corresponde a um pre-plano de projecto, sendo composto pela analise inicial da

oportunidade classificada como projecto. E utilizado para obter autorizacao e identificar o responsavel

pelo projecto, reunindo toda a analise realizada na fase de oportunidade. E considerado pela maioria

das referencias em gestao de projecto como um documento que fornece autorizacao ao gestor de pro-

jecto para aplicar um conjunto de recursos da organizacao a actividades do projecto. Num paralelismo

com as oportunidades de projecto, definimos o maintenance charter, um documento que possui os

mesmos objectivos do project charter mas aplicado as oportunidades de manutencao.

A fase de oportunidade termina com a integracao das oportunidades em portfolios de projectos

ou de manutencoes, que agrupam um conjunto de oportunidades geridas em conjunto para alcancar

objectivos estrategicos da organizacao. Todos os documentos de suporte identificados na fase de

oportunidade sao detalhados na tabela A.1 no anexo A.1.

Tendo em conta a matriz de CRUF da fase de oportunidade, representada na tabela 4.5, todos

os documentos desta fase sao criados pela area de projectos ou de manutencao por serem unicos a

oportunidade recebida, com excepcao dos portfolios de projectos e manutencoes que sao comuns a

todas as manutencoes e projectos levados a cabo pela direccao de sistemas de informacao.

A vista de informacao encontra-se intimamente ligada com a vista de responsabilidades, na medida

em que as entidades que criam e alteram os documentos sao, na sua maioria, as mesmas entidades

responsaveis pela execucao das actividades nas quais esses documentos sao produzidos. E o caso do

project charter e do maintenance charter, criados e actualizados na fase de oportunidade pela area de

projectos e pela area de manutencao, respectivamente.

Importa tambem destacar a interaccao apenas de consulta para os portfolios de projectos e de

manutencoes por parte do director DSI. Tendo em conta que nao estamos a considerar aspectos de

gestao de Portfolio, assume-se que o director DSI nao executa qualquer tipo de analise e alteracoes aos

38

Documentos de suporte Projectos O&M P&C Director DSI Negocio

Registo da oportunidade C/U R R R

Caso de negocio C/U R R R

Statement of work C/U R R R

Project charter C/U R R R

Maintenance charter R C/U R R

Portfolio de projectos C/U R R

Portfolio de manutencoes C/U R R

Tabela 4.5: Matriz CRUF dos documentos de suporte da fase de oportunidade.

projectos e manutencoes pertences aos portfolios, sendo por isso uma interaccao apenas de consulta.

4.3 Fase de Planeamento

A fase de planeamento inicia-se com uma revisao da analise da oportunidade e com a definicao dos

planos de gestao de stakeholders, gestao de comunicacoes e gestao de risco. E nesta fase que tambem

e realizado todo o processo de compra da implementacao do projecto em outsourcing, sendo definido o

plano de gestao de compra e realizadas a consulta ao mercado, a seleccao da proposta a adjudicar e a

definicao do contracto de compra. Apos este processo de compra, e feito o planeamento de calendario

e custos do projecto, sendo definidos os planos de gestao de calendario e de gestao de custos. No final

desta fase e dado inıcio ao processo de implementacao do projecto.


Apos a fase de oportunidade, as oportunidades de manutencao encontram-se integradas em servicos

de manutencao ou agendadas para implementacao, possuindo a organizacao processos especıficos

para a sua gestao. No que diz respeito as oportunidades de projecto, estas encontram-se integradas

num portfolio de projectos, cujo orcamento e calendario se encontra bem definido em termos de

portfolio. Porem, e necessario realizar todo o planeamento do projecto individualmente, de forma a

detalhar toda a analise realizada na fase de oportunidade apresentada no project charter.

A fase de planeamento inicia-se com a gestao de stakeholders, de riscos e de comunicacoes, que

procura aprofundar toda a analise realizada na fase de oportunidade e definir os respectivos plano de

gestao. O fluxo do processo relativo a estas actividades e apresentado na figura 4.4.

No inıcio da fase e revisitado todo o planeamento da oportunidade realizado, com a revisao do

statement of work e do caso de negocio face aos novos desenvolvimentos do projecto. E tambem anal-

isada toda a informacao detalhada no project charter relativa a stakeholders do projecto, especificacoes

tecnicas, requisitos funcionais e riscos identificados. No final desta actividade o project charter, iniciado

na fase de oportunidade, e encerrado, passando toda a analise revista a fazer parte do plano de gestao

de projecto, que ira reunir todo o planeamento e controlo do mesmo ate ao seu encerramento. O gestor

de projecto define ainda o conjunto de responsabilidades no planeamento do projecto por parte dos

39

Figura 4.4: Fluxo do processo relativo a gestao de stakeholders, riscos e comunicacoes na fase deplaneamento.

elementos da sua equipa, sendo definido um plano de trabalho para esta fase.

A gestao de stakeholders do projecto e iniciada pela identificacao de indivıduos, grupos ou organizacoes

que afectam ou sao afectados pelo projecto. Esta actividade e especialmente importante tendo em

conta que estes elementos sao partes integrantes de todo o processo, possuindo informacao relevante

e um conjunto de interesses que sera fundamental para o sucesso do projecto. E realizado um levanta-

mento de informacao de stakeholders, que ira complementar toda a informacao ja recolhida durante a

fase de oportunidade. Apos o levantamento da informacao, sao realizadas um conjunto de entrevistas

e avaliacoes de stakeholders em termos de requisitos, expectativas e impacto no projecto de acordo

com os metodos de avaliacao adoptados pela organizacao. Considerando esta avaliacao, e possıvel

definir um perfil para cada stakeholder, identificando o seu posicionamento face ao projecto em termos

de participacao, resistencia ou apoio. No final da actividade sao realizadas reunioes de familiarizacao

com os stakeholders, com o objectivo de aproxima-los com a equipa e com todo o processo de desen-

volvimento do projecto, facilitando futuras comunicacoes.

Numa segunda fase, e elaborado o plano de gestao de stakeholders, que integrara o plano de

gestao de projecto e possibilitara compreender e gerir as necessidades e expectativas de cada um dos

stakeholders identificados. Sera realizada uma analise de participacao dos stakeholders nas fases de

projecto, identificando a sua importancia e em que termos esta participacao sera feita. Serao tambem

identificadas actividades de comunicacoes com os stakeholders, desde as previstas pelos mesmos

como requisitos de planeamento do projecto ate a sugestoes de novas comunicacoes identificadas

pela equipa de projecto. Tendo em conta que existem um conjunto de stakeholders distintos, com

diferentes objectivos e interesses, sera necessario realizar uma analise de relacoes entre stakeholders

e de impacto de alteracoes. Em momentos de negociacao com stakeholders e necessario uma grande

diplomacia e gestao de interesses, pelo que esta analise sera fundamental de forma a ir ao encontro

das expectativas de todos os interessados no projecto.

Nesta fase do processo e tambem definido o plano de gestao de riscos, assegurando que oportu-

nidades e ameacas que introduzam um grau de incerteza no projecto sejam geridas de acordo com os

objectivos da organizacao e dos stakeholders. Assim, e definido o metodo de gestao de risco a utilizar

no projecto, muitas vezes proprietario da propria organizacao que identifica todas as actividades a re-

alizar nas varias fases da gestao do risco e de que forma estas devem ser coordenadas entre si. Sao

definidas responsabilidades no processo de gestao de risco e realizada uma estimativa de orcamento

40

para a gestao de risco. Esta estimativa ira ser incluıda no orcamento global do projecto e tem como

objectivo cobrir todas as despesas envolvidas nas actividades de gestao de risco e nos planos de con-

tingencia. E tambem feita a calendarizacao de todas as actividades, sendo detalhadas a duracao e

periodicidade de actividades de identificacao, analise e tratamento de risco. Directamente relacionado

com o planeamento de comunicacoes, sera definido o metodo de registo e comunicacao do processo

de gestao de risco, que embora se encontre definido no metodo considerada, sera alvo de pequenos

ajustes de acordo com o projecto especıfico a que se destina.

Terminado o planeamento da gestao de stakeholders e do risco, e realizado o planeamento de

comunicacoes, com a definicao do plano de gestao de comunicacoes. Est actividade tem ja em conta

um conjunto de resultados em termos de comunicacao das actividades anteriores, nomeadamente no

planeamento de comunicacoes com os stakeholders e no processo de gestao de risco. Nesta actividade

sao definidos os requisitos, como a periodicidade e frequencia da comunicacao, intervenientes e canais

de comunicacao do projecto, bem como metodos e tecnologias a utilizar. Sera ainda definido um

conjunto de responsabilidades nas comunicacoes planeadas no projecto.

Apos o planeamento de comunicacoes, e dado inıcio ao procedimento de compra e posterior definicao

do plano de gestao de calendario e do plano de gestao de custos, como apresentado na figura 4.5.

Figura 4.5: Fluxo do processo relativo ao procedimento de compra e gestao de calendario e de custos.

Durante a compra, a execucao das actividades passam a ser responsabilidade da area de compras,

que actua de acordo com processos definidos e regulamentados pela organizacao. Importa destacar

que o procedimento de compra e intrınseco a cada organizacao, dependendo de aspectos organicos da

mesma. Organizacoes publicas e privadas, por exemplo, possuem processos de compra distintos na

medida em que sao alvo de diferentes regulamentacoes ou geridas de acordo com polıticas distintas.

O procedimento de compra desenhado possui como principais referencias os processos de compra

apresentados pela ISO 21500 e pelo PMBOK, sendo complementados pelo caso real considerado,

distanciando-se do praticado actualmente na organizacao e correspondendo a uma proposta generica

de um procedimento de compra. As actividades detalhadas sao apresentadas na tabela 4.6.

A preparacao das actividades de compra inicia-se com o planeamento da compra, sendo definida

41

Actividades

GPM-PL6 - Planeamento da compra - Preparacao das actividades de compra com a definicao da especificacaotecnica, criterios de avaliacao de propostas e plano de gestao de compra.

GPM-PL6.1 - Definicao e validacao da especificacao tecnica e dos requisitos da compra para integrar o procurement statementof work.

GPM-PL6.2 - Revisao do orcamento do projecto com a definicao do orcamento detalhado da compra de acordo com o planoanual de compras da direccao dos sistemas de informacao.

GPM-PL6.3 - Definicao do calendario da compra de acordo com as milestones de compras definidas no plano anual decompras da direccao dos sistemas de informacao.

GPM-PL6.4 - Identificacao e analise de riscos de compras.

GPM-PL6.5 - Definicao dos criterios de avaliacao das propostas de parceiros.

GPM-PL6.6 - Reuniao de validacao do procedimento de compra.

GPM-PL7 - Consulta ao mercado - Inıcio do perıodo de consulta ao mercado, com a recepcao de propostas de par-ceiros e realizacao de pedidos de esclarecimentos.

GPM-PL7.1 - Abertura do perıodo de consulta ao mercado de acordo com o calendario da compra.

GPM-PL7.2 - Criacao de carteira de propostas a adjudicar pela organizacao para a implementacao do projecto.

GPM-PL7.3 - Realizacao de pedidos de esclarecimentos relativos a propostas de parceiros.

GPM-PL8 - Seleccao da proposta - Avaliacao das propostas recebidas contra os criterios de avaliacao estabelecidos,resultando na escolha da proposta do parceiro a adjudicar.

GPM-PL8.1 - Avaliacao de propostas recebidas de acordo com criterios de avaliacao estabelecidos.

GPM-PL8.2 - Seleccao da proposta a adjudicar pela organizacao para implementacao do projecto.

GPM-PL8.3 - Actualizacao e validacao do orcamento da compra com a proposta seleccionada.

GPM-PL9 - Definicao do contracto de compra - Preparacao da minuta do contracto de compra e envio da nota deencomenda.

GPM-PL9.1 - Definicao da minuta de contracto de compra.

GPM-PL9.2 - Reuniao de validacao da minuta de contracto de compra.

GPM-PL9.3 - Adjudicacao da compra com envio da nota de encomenda.

Tabela 4.6: Actividades detalhadas do procedimento de compra.

e validada a especificacao tecnica de compra que apresenta, com detalhe variavel de acordo com o

ambito do projecto, uma analise tecnica da solucao a desenvolver, identificando que componentes de-

vem ser desenvolvidos e de que forma serao integrados. Esta especificacao pode corresponder apenas

ao statement of work, desenvolvido na fase de oportunidade e que apresenta apenas os produtos ou

servicos a disponibilizar pelo projecto, ou pode corresponder ja a uma analise tecnica deste documento,

caso a equipa de projecto possua elementos com os conhecimentos tecnicos necessarios. Neste pro-

cesso, consideramos que a area de projectos e capacitada do conhecimento necessario para analisar

o statement of work numa perspectiva mais tecnica e elaborar um desenho da solucao a desenvolver,

a partir do qual sera feita a especificacao tecnica da compra.

E tambem revisto o orcamento do projecto, definido durante a fase de oportunidade e integrado

no orcamento anual da organizacao como um projecto pertencente ao portfolio de projectos. Este

orcamento foi definido tendo em conta a compra da implementacao do projecto, razao pela qual e

definido nesta fase o orcamento da compra e incluıdo no plano de gestao de compra. A definicao deste

orcamento tem dois objectivos: garantir que o orcamento da compra se encontra de acordo com o

orcamento global do projecto definido no portfolio e definir um tecto orcamental para a compra, que

42

servira tambem como criterio de avaliacao de propostas.

O calendario das compras e definido nesta fase, sendo necessario alinhar as actividades de compra

do projecto com as restantes actividades de compra da organizacao, de acordo com um plano anual

de compras definido a nıvel da governacao da direccao dos sistemas de informacao. Este calendario

de compra define as principais milestones de compra na perspectiva da area de projectos, tendo em

conta que nao existe ainda qualquer parceiro responsavel pela implementacao. Normalmente este

calendario define apenas datas de inıcio de compra e datas expectaveis de entregas do parceiro, uteis

na definicao do procurement statement of work permitindo ao parceiro avaliar se tem capacidade para

cumprir o calendario.

De forma a avaliar o conjunto de futuras propostas de parceiros, sao tambem definidos um conjunto

de criterios de avaliacao de propostas, que identificam criterios para a escolha da proposta a adjudicar.

A identificacao dos criterios tem em conta aspectos intrınsecos ao ambito do projecto, podendo reflectir

criterios orcamentais ou tecnicos, entre outros. Antes de iniciar a compra, e realizada uma reuniao de

validacao do procedimento de compra, sendo validados o planeamento da compra e o procurement

statement of work. Esta revisao garante que todo o procedimento da compra foi definido em acordo

entre a area de projectos e a area de compras.

A abertura do perıodo de consulta ao mercado, com data definida no calendario da compra, marca

o inıcio de recepcao de propostas dos parceiros, que avaliaram o procurement statement of work

fornecido e definiram uma proposta de implementacao do projecto. Durante o perıodo de consulta

ao mercado e criada pela area de compras uma carteira de propostas, podendo estas propostas serem

alvo de pedidos de esclarecimentos promovidos tanto pela organizacao como pelos possıveis par-

ceiros. Apos o fim da consulta ao mercado, e realizada a avaliacao das varias propostas recebidas e

selecionada a proposta a adjudicar. Finalizada a escolha da proposta a adjudicar, a compra e oficial-

izada com a definicao da minuta do contracto de compra e com o envio da nota de encomenda por

parte da organizacao.

Apos o procedimento de compra finalizado, e possıvel a equipa de projecto detalhar o orcamento

e calendario do projecto, sendo definidos os planos de gestao de calendario e de gestao de custos.

Durante o planeamento de orcamento do projecto e definida a baseline de orcamento do projecto, que

correponde a primeira versao do orcamento detalhado do projecto, cujos tracos gerais ja se encontram

definidos no orcamento anual da direccao dos sistemas de informacao e integrado no portfolio de pro-

jectos, mas que necessita de ser detalhado tendo em conta todo o procedimento de compra e o custo

da implementacao do mesmo. E no planeamento de custos de projecto que tambem e desenvolvido o

plano de pagamentos, que define datas e valores monetarios a cobrar pelo parceiro de acordo com a

proposta seleccionada. O plano de pagamentos envolve apenas a compra da implementacao tendo em

conta que o projecto e interno a organizacao, sendo o seu custo parte do orcamento anual da mesma.

O planeamento de calendario do projecto define e calendariza detalhadamente as actividades a

realizar durante a execucao do projecto, sendo apresentadas as principais milestones do projecto em

termos de calendario e definida a baseline de calendario do projecto, que servira como ponto de re-

ferencia para todo o controlo de calendario do projecto. No final da fase de planeamento, o Plano de

43

gestao de projecto e revisto na sua totalidade antes do inıcio da implementacao do mesmo, sendo re-

visitados os planos de gestao de stakeholders, de gestao de risco e de gestao de comunicacoes com

a participacao do parceiro. De forma a dar inıcio a fase de implementacao e controlo, sao realizadas

duas reunioes de kick-off do projecto, uma interna com a equipa de projecto e a area de negocio e

outra externa da equipa de projecto com o parceiro.


Durante toda a fase de planeamento a area de projectos desempenha o principal papel em todas as

actividades, sendo responsavel pela execucao e controlo de progresso na revisao do planeamento de

projecto e na definicao dos planos de gestao de stakeholders, de comunicacoes, de riscos, de custos e

de calendario.

Na gestao de stakeholders, a area de projectos conta com a colaboracao da area de negocio, que

reune os principais stakeholders do projecto, sendo esta consultada em reunioes de familiarizacao e

entrevistas. O mesmo sucede na gestao de comunicacoes, contando tambem com a consulta as areas

de O&M, planeamento e controlo e ao director DSI de forma a definir todo o plano de comunicacao. Em

termos de gestao de risco, possui especial relevo a consulta a area de planeamento e controlo para a

definicao do orcamento a alocar para actividades de gestao de risco.

A gestao de custos do projecto e realizada em estrita colaboracao com a area de planeamento e

controlo, sendo esta consultada em todas as actividades pois e a area responsavel pelo orcamento

anual da direccao dos sistemas de informacao e qualquer posicao orcamental, tomada pela area de

projectos, necessita de ser tida em conta por esta area. Na gestao de calendario os principais interve-

nientes consultados sao o parceiro seleccionado para a implementacao do projecto e a area de negocio.

O parceiro, apesar de estar de acordo com um calendario de compra definido na proposta adjudicada,

fornece o feedback necessario para a calendarizacao de actividades a um nıvel de detalhe superior

ao que consta no plano de compra. Relativamente a area de negocio, e esta a principal entidade que

introduz constragimentos na calendarizacao de actividades e definicao de milestones, razao pela qual

e consultada.

O procedimento de compra apresenta uma definicao de responsabilidades distinta de toda a restante

fase, sendo a responsabilidade de execucao e controlo de progresso das actividades da area de Com-

pras. E esta a area que conta com os especialistas em todos os procedimentos de compra, desde

a seleccao de parceiros de implementacao ate a definicao de contractos. Na tabela 4.7 encontra-se

detalhada a vista de responsabilidades para todo o procedimento de compra desenhado.

No planeamento da compra a area de projectos assume a responsabilidade de execucao das activi-

dades e controlo de progresso, na medida em que todas as actividades estao directamente relacionadas

com o projecto em si e a area de compras nao possui o conhecimento especıfico do projecto para as

realizar. Importa destacar a consulta a area de compras na definicao do calendario de compras e dos

criterios de avaliacao das propostas, sendo necessarias trocas de informacao no processo entre es-

tas duas areas que permitirao a passagem de responsabilidade durante o procedimento de compra.

44

Actividades Projectos O&M P&C Compras Director

DSIParceiro Negocio

GPM-PL6 - Planeamento da Compra

GPM-PL6.1 X/P/D A A

GPM-PL6.2 X/P C I I

GPM-PL6.3 X/P I C A

GPM-PL6.4 X/P C C A

GPM-PL6.5 X/P A C A

GPM-PL6.6 X/P I I I I

GPM-PL7 - Consulta ao mercado

GPM-PL7.1 I X/P I

GPM-PL7.2 C X/P C

GPM-PL7.3 C X/P C

GPM-PL8 - Seleccao da proposta

GPM-PL8.1 C X/P I

GPM-PL8.2 C/d X/P/D I/d I I

GPM-PL8.3 X I P

GPM-PL9 - Definicao do contracto de compra

GPM-PL9.1 C C X/P/D C/d

GPM-PL9.2 C C X/P C C

GPM-PL9.3 I I X/P/D I I I

Tabela 4.7: Vista de responsabilidades detalhada do procedimento de compra na fase de planeamento.

A area de compras possui uma vasta experiencia, pelo que integra a identificacao e analise de riscos

bem como a definicao do calendario da compra. Em termos de definicao dos criterios de avaliacao,

a area de compras possui um papel ainda mais importante, embora mantido como consulta, podendo

ela propria definir criterios especıficos. Em termos da definicao de orcamento, a area de planemento e

controlo e consultada na revisao do orcamento da compra.

Na consulta ao mercado a area de projectos e consultada na criacao da carteira de portfolios e na

realizacao de pedidos de esclarecimento por ser ela a possuir os conhecimentos tecnicos necessarios

para avaliar potenciais falhas na proposta recebida ou aspectos nao definidos pelo parceiro. Na seleccao

da proposta, a decisao da proposta a adjudicar e tomada em colaboracao entre a area de compras,

o director DSI e a area de projectos. Devido a sua responsabilidade na direccao dos sistemas de

informacao, o director DSI possui sempre uma posicao de decisao na seleccao da proposta, embora

esta decisao seja, na grande maioria dos casos, de acordo com os restantes elementos tendo em conta

que nao possui o conhecimento detalhado do projecto. A area de projectos participa tambem na de-

cisao, numa perspectiva de analise tecnica da proposta. A decisao final e da area de compras, que de

acordo com os criterios de avaliacao definidos, selecciona a melhor proposta apresentada. A minuta

do contracto de compra e a nota de encomenda sao definidas e aprovadas pela area de compras, com

as areas de projectos e planeamento e controlo a serem consultadas e o director DSI a tomar parte da

decisao de aprovacao da minuta.

45


A fase de planeamento e marcada pelo fecho do project charter e inıcio da definicao do plano de gestao

de projecto, que ira incluir todos os planos de gestao definidos ao longo desta fase e acompanhar

toda a gestao do projecto ate ao seu encerramento. Na revisao do planeamento de projecto e feita

a revisao e inclusao de toda a informacao do project charter no plano de gestao de projecto, que

ao longo de toda a fase ira contar tambem com a inclusao dos planos de gestao de stakeholders,

de comunicacoes, de riscos, de compra, de custos e de calendario. Todos estes planos de gestao sao

definidos individualmente, sendo depois incluıdos no plano de gestao de projecto de forma a possuir um

unico repositorio de informacao do projecto. Todos os documentos de suporte a fase de planeamento

do processo sao identificados na tabela A.2 do anexo A.2, sendo detalhados os objectivos da sua

utilizacao e a informacao constante em cada um deles.

Considerando a matriz de CRUF da fase de planeamento, representada na tabela 4.8, todos os

planos de gestao secundarios sao criados pela area de projectos, que executa tarefas relativas a sua

definicao, sendo tambem a responsavel pela actualizacao dos mesmos. As interacoes de consulta sao

da responsabilidade dos elementos que na vista de responsabilidades sao informados e consultados,

justificadas pela necessidade de conhecer toda a informacao disponıvel do projecto.

O caso de negocio, o statement of work e o project charter, criados na fase de oportunidade, sao

encerrados no inıcio da fase de planeamento pela area de projectos, deixando de existir como docu-

mentos individuais e sendo integrados no plano de gestao de projecto. Esta decisao e justificada pela

necessidade de criacao de um repositorio central de informacao, nao havendo qualquer tipo de van-

tagem em manter estes tres documentos individuais. Antes de serem integrados no plano de gestao de

projecto, e realizada a revisao e actualizacao de toda a informacao constante dos mesmos.

A definicao da proposta de compra e feita em colaboracao entre a area de compras, responsavel

pela regulamentacao de todo o procedimento de compra, a area de projectos e o parceiro, que apre-

senta a proposta. Como consequencia, estas tres entidades possuem interacoes de actualizacao na

medida em que a definicao da proposta de compra e feita iterativamente, com um conjunto de alteracoes

provenientes de qualquer uma destas tres entidades. Em termos da minuta do contracto de compra e

da nota de encomenda a situacao e semelhante, existindo varias entidades envolvidas no processo de

desenvolvimento do documento e que possuem interesses individuais na sua definicao.

4.4 Fase de Implementacao e Controlo

A fase de Implementacao e Controlo inicia-se com o inıcio da implementacao por parte do parceiro e

com o controlo de projecto por parte da area de projectos. Esta fase nao possui um fluxo unico, con-

sistindo num conjunto de processos individuais que permitem todo o controlo do projecto. Durante todas

as semanas sao feitas reunioes semanais de projecto, onde poderao surgir novos riscos, issues e pe-

didos de alteracao ao projecto. E tambem realizada, todos os meses, uma reuniao mensal do projecto,

que possui um caracter mais estrategico e procura analisar os riscos, issues e alteracoes com maior

46

Documentos de suporte Projectos O&M P&C Compras Director

DSIParceiro Negocio

Caso de negocio R/F R R

Statement of work R/F R

Project charter R/F R R R

Plano de gestao de projecto C/R/U R R R

Registo de stakeholders C/R/U R

Plano de gestao de stakeholders C/R/U R

Log de riscos C/R/U R R R

Plano de gestao de riscos C/R/U R R R

Plano de gestao de comunicacoes C/R/U R R R

Procurement statement of work C/R/U R R R R

Criterios de avaliacao de propostas C/R/U R R R

Plano de gestao de compra C/R/U R R R R

Proposta de compra R/U R/U R C/R/U

Minuta de contracto de compra R/U R C/R/U R/U R/U

Nota de encomenda R/U C/R/U R R

Plano de gestao de custos C/R/U R R

Plano de Gestao de calendario C/R/U R R R

Tabela 4.8: Matriz CRUF dos documentos de suporte ao processo na fase de planeamento.

impacto e prioridade bem como fazer uma revisao geral de calendario e orcamento do projecto. Sem-

pre que novos riscos, alteracoes ou issues sao identificados, sao iniciados os processos de gestao de

risco, gestao de alteracoes ou gestao de issues, respectivamente. A fase de implementacao e controlo

termina com a entrega da implementacao por parte do parceiro, iniciando-se a fase de handover.

Tendo em conta a nao existencia de um fluxo unico do processo nesta fase, a vista de processos

sera dividida nos processos individuais que dela fazem parte, sendo detalhados os que se consideram

com maior interesse no ambito deste trabalho.


4.4.1.1 Controlo Semanal do Projecto

O controlo semanal do projecto e constituido por uma so macro-actividade, identificada na figura 4.6,

podendo despoletar outros processos durante a sua execucao caso certas condicoes sejam verificadas.

Este controlo possui um caracter mais operacional, tendo como objectivos definir o conjunto de activi-

dades a executar pela equipa de projecto durante a semana e realizar o controlo de custos, calendario,

riscos, issues, alteracoes, comunicacoes e stakeholders, de forma a garantir o cumprimento dos re-

spectivos planos de gestao.

Durante o controlo semanal do projecto sao identificados novos riscos, issues e pedidos de alteracao

que tenham surgido durante a semana, dando inıcio aos respectivos processos de gestao. Esta macro-

47

Figura 4.6: Fluxo do processo de controlo semanal do projecto.

actividade tem a duracao da semana de trabalho da equipa, sendo iniciada no primeiro dia da semana e

culminando na elaboracao do relatorio de progesso semanal a ser disponibilizado ao director DSI, que

a cada semana recebe o feedback do progresso do projecto. Durante a semana e tambem realizado o

controlo do tratamento dos riscos identificados no projecto, com a analise dos prametros de probabili-

dade e risco residual dos mesmos, e o controlo dos pedidos de alteracao por aprovar, aprovados e em

implementacao.

E ainda necessario garantir que toda a informacao e disponibilizada de acordo com o plano de

comunicacoes, garantindo o seu cumprimento e a chegada da informacao a todos os interessados. Da

mesma forma, e necessario garantir que a participacao dos stakeholders e realizada de acordo com o

plano de gestao de stakeholders, sendo continuamente identificadas propostas de alteracoes, avaliado

o seu impacto e garantida a satisfacao dos seus principais concerns.

As actividades detalhadas de controlo semanal de projecto sao identificadas na tabela 4.9.

4.4.1.2 Controlo Mensal do Projecto

O controlo mensal do projecto, apresentado na figura 4.7, e iniciado no primeiro dia do mes, destacando-

se do controlo semanal no grau de detalhe analisado, pretendendo-se uma visao mais alto nıvel do

progresso do projecto. E realizada uma revisao do calendario do projecto tendo em conta o conjunto

de milestones definidas e a respectiva discrepancia face ao progresso actual. E tambem elaborado um

forecast de orcamento do projecto, que apresenta uma previsao do orcamento de projecto baseada em

estimativas futuras e que permite avaliar a discrepancia face a baseline de orcamento do projecto.

E tambem realizada a revisao do plano de gestao de comunicacoes, com ajustes a necessidades

de comunicacao, informacoes a disponibilizar ou intervenientes, mantendo este plano actualizado de

acordo com os requisitos de comunicacao do projecto. De forma semelhante, o plano de gestao de

48

Actividades

GPM-SE1 – Controlo semanal de projecto – Gestao operacional em formato semanal de orcamento, calendario, riscos,issues, alteracoes, comunicacoes e stakeholders do projecto.

GPM-SE1.1 - Controlo de orcamento do projecto face aos tresholds e a baseline de orcamento definidos no plano de gestaode custos do projecto;

GPM-SE1.2 - Controlo de calendario do projecto face aos tresholds e a baseline de calendario definidos no plano de gestaode calendario do projecto;

GPM-SE1.3 - Atribuicao de actividades de projecto pelo gestor de projecto a equipa;

GPM-SE1.4 - Identificacao de novos riscos do projecto que tenham surgido durante a semana;

GPM-SE1.5 - Controlo do tratamento de riscos planeado para o conjunto de riscos do projecto.

GPM-SE1.6 - Identificacao de alteracoes que tenham surgido durante a semana ao plano de projecto;

GPM-SE1.7 - Controlo de alteracoes para aprovar, aprovadas e em implementacao;

GPM-SE1.8 - Identificacao de issues de projecto que tenham surgido durante a semana;

GPM-SE1.9 - Gestao de comunicacoes com base no plano de gestao de comunicacoes, com a revisao da informacao adisponibilizar, intervenientes e metodos de comunicacao;

GPM-SE1.10 - Gestao de stakeholders do projecto com base no plano de gestao de stakeholders, com a revisao da suaparticipacao em actividades de projecto, comunicacoes e impacto de alteracoes;

GPM-SE1.11 – Elaboracao do Relatorio de Progresso semanal a ser disponibilizado pela equipa ao director DSI para registode progresso do projecto.

Tabela 4.9: Actividades detalhadas do processo de controlo semanal do projecto.

Figura 4.7: Fluxo do processo de controlo mensal do projecto.

stakeholders tambem e revisto com possıveis actualizacoes no registo de stakeholders. Por ultimo, e

realizada uma avaliacao dos riscos com maior prioridade identificados durante o mes, com o controlo

de tratamento desses mesmos riscos, garantindo que os mais crıticos sao geridos de forma a evitar

consequencias danosas para o projecto.

No final do controlo mensal do projecto, que possui uma duracao variavel face a extensao das

analises anteriores, e produzido o relatorio de progresso mensal do projecto para acompanhamento

do estado do projecto pelas areas de planeamento e controlo, director DSI e negocio. Ja com toda

a informacao disponıvel, e realizada uma reuniao de controlo mensal com a area de negocio, para

apresentacao do relatorio de progresso mensal do projecto, podendo desta reuniao surgir a identificacao

de novos riscos, issues ou alteracoes.

Tendo em conta o forecast de orcamento e o caso real da organizacao, na definicao da versao apli-

49

cada ao caso real da organizacao, foi considerada uma extensao ao controlo mensal do projecto. O

forecast de orcamento de projecto seria revisto pela area de planeamento e controlo, sendo realizada

uma analise de necessidade de alteracao ao orcamento do projecto tendo em conta a discrepancia

com a baseline. No caso de serem necessarias alteracoes, a area de planeamento e controlo seria re-

sponsavel por propor um conjunto de alteracoes ao orcamento, que seriam submetidas para aprovacao

ao director DSI, o qual iria proceder a uma analise e tomar a decisao de aprovacao. Apesar de ser um

processo comum em grande parte das organizacoes, optamos por nao detalhar estas actividades por

serem intrınsecas a organizacao, apresentando necessariamente variacoes se outro caso real de outra

organizacao fosse considerado.

As actividades detalhadas de controlo mensal de projecto sao identificadas na tabela 4.10.

Actividades

GPM-ME1 - Controlo mensal do projecto - Gestao estrategica em formato mensal de orcamento, calendario, riscos,alteracoes, comunicacoes e stakeholders do projecto.

GPM-ME1.1 - Revisao de milestones contratuais e etapas de projecto para revisao e actualizacao do calendario de projecto,de forma a avaliar nıvel de discrepancia com a baseline de calendario;

GPM-ME1.2 - Elaboracao de forecast de orcamento de forma a avaliar nıveis de discrepancia com a baseline de orcamento;

GPM-ME1.3 - Revisao dos riscos com maior prioridade identificados, com o controlo de tratamento desses riscos.

GPM-ME1.4 - Avaliacao da necessidade de pedido de alteracao de orcamento, calendario ou ambito de acordo com osforecasts e analises produzidas e os tresholds de controlo definidos nos respectivos planos.

GPM-ME1.5 - Revisao do plano de gestao de comunicacoes do projecto com ajustes a necessidades de comunicacao,informacao a disponibilizar, intervenientes e ferramentas de comunicacao.

GPM-ME1.6 - Revisao do plano de gestao de stakeholders com ajustes na identificacao de stakeholders, comunicacoes ouimpacto de alteracoes.

GPM-ME1.7 - Producao e envio de relatorio de progresso mensal do projecto para acompanhamento do estado do projectopelas areas de planeamento e controlo, director DSI e negocio.

GPM-ME1.8 - Reuniao de controlo mensal do projecto com a participacao da area de Negocio, para apresentacao do relatoriode progresso do projecto, com possıvel identificacao de novos riscos, issues e alteracoes.

Tabela 4.10: Actividades detalhadas do processo de controlo mensal do projecto.

4.4.1.3 Gestao de Riscos do Projecto

Sempre que um risco e identificado durante a fase de planeamento e as fases seguintes, e iniciado o

processo de gestao de riscos identificado na figura 4.8. O processo inicia-se com o registo do risco no

log de riscos, sendo definido o responsavel pelo mesmo e ainda realizada uma identificacao preliminar

das causas, consequencias, areas de impacto e possıveis medidas de tratamento do risco. Esta analise

preliminar tem como objectivo recolher a maxima informacao disponıvel no momento de identificacao

do risco, facilitando a posterior fase de analise em que alem de complementar todas as informacoes, o

risco e ainda prioritizado. A prioridade do risco e definida em termos da analise de impacto realizada,

a probabilidade do risco e ainda o nıvel de exposicao ao risco da organizacao, definido no plano de

gestao de riscos. Este nıvel de exposicao ao risco identifica, em funcao da probabilidade e impacto do

risco, qual o nıvel de risco maximo que a organizacao esta disposta a aceitar, aceitando esse mesmo

nıvel de risco como uma oportunidade de negocio.

O tratamento do risco e divido em tres macro-actividades. Em primeiro lugar sao levantadas um

50

Figura 4.8: Fluxo do processo de identificacao e analise do risco.

conjunto de medidas aplicaveis ao tratamento do risco, sendo realizada uma analise de orcamento

e calendario das mesmas. O objectivo e fazer um levantamento de todas as medidas disponıveis

para seleccionar um conjunto delas que, aplicadas, permitem reduzir o nıvel de risco ate a um nıvel

residual aceitavel pela organizacao. A ultima fase consiste na definicao do plano de tratamento, que e

adicionado ao log do risco e que define as medidas a aplicar e respectivas actividades, os responsaveis

e o orcamento para o tratamento do risco, entre outras informacoes. O fluxo do processo relativo as

actividades de seleccao das medidas de tratamento de risco e de definicao do plano de tratamento sao

apresentadas na figura 4.9.

Figura 4.9: Fluxo do processo de tratamento do risco.

O controlo do tratamento dos riscos nao e definido neste processo, fazendo parte dos controlos

semanais e mensais do projecto por ser variavel em funcao das medidas consideradas. Consiste na

avaliacao dos nıveis de risco residuais e da necessidade de aplicacao de novas medidas de tratamento

do risco. Na tabela 4.11 sao apresentadas as actividades detalhadas do processo de gestao de risco.

4.4.1.4 Gestao de Issues do Projecto

Assim que um issue de projecto e identificado, podendo ter um conjunto de origens distintas e normal-

mente associado a riscos que se concretizaram, e iniciado o processo de gestao de issues apresentado

51

Actividades

GPM-RI1 - Registo do risco - Registo, identificacao de responsavel e analise preliminar das causas, consequenciase impacto do risco identificado.

GPM-RI1.1 - Registo do risco no log de riscos;

GPM-RI1.2 - Definicao de responsavel pelo risco;

GPM-RI1.3 - Identificacao preliminar das causas, consequencias e areas de impacto do risco;

GPM-RI1.4 - Levantamento preliminar de possıveis medidas de tratamento do risco;

GPM-RI2 - Analise do risco - Identificacao das causas, consequencias, impacto, probabilidade e prioridade do riscoidentificado tendo em conta todo o plano de projecto.

GPM-RI2.1 - Identificacao das causas e consequencias do risco;

GPM-RI2.2 - Determinacao de probabilidade do risco;

GPM-RI2.3 - Analise de impacto do risco no orcamento, calendario e ambito do projecto;

GPM-RI2.4 - Prioritizacao do risco de acordo com analise de impacto realizada, prioridade do risco e exposicao ao risco daorganizacao de acordo com o plano de gestao de riscos;

GPM-RI3 - Identificacao de medidas de tratamento do risco - Levantamento de medidas de tratamento com analisede orcamento e calendario para a sua implementacao.

GPM-RI3.1 - Levantamento de conjunto de medidas aplicaveis ao tratamento do risco.

GPM-RI3.2 - Identificacao de estimativa de orcamento e calendario para a aplicacao de cada uma das medidas de tratamentodo risco identificadas.

GPM-RI4 - Seleccao de medidas de tratamento de risco - Escolha das medidas de tratamento de risco a aplicar deacordo com o orcamento e calendario definido e analise de risco residual.

GPM-RI4.1 - Seleccao de medida de tratamento de risco a aplicar, de acordo com a estimativa de orcamento e calendariodefinidas para a medida;

GPM-RI4.2 - Estimativa de nıvel de risco residual e decisao de aplicacao de novas medidas de tratamento de risco;

GPM-RI5 - Definicao de plano de tratamento de risco - Definicao do plano de tratamento do risco com a identificacaodas medidas a implementar, orcamento e calendario das actividades.

GPM-RI5.1 - Definicao de conjunto de medidas a implementar e responsavel para o tratamento do risco;

GPM-RI5.2 - Definicao e calendarizacao de actividades de tratamento de risco;

GPM-RI5.3 - Revisao do orcamento e calendario das medidas de tratamento aplicaveis com o calendario e orcamento doprojecto;

GPM-RI5.4 - Identificacao das condicoes trigger de probabilidade de ocorrencia do risco;

GPM-RI5.5 - Identificacao do nıvel de risco residual;

Tabela 4.11: Actividades detalhadas do processo de gestao de risco do projecto.

na figura 4.10. O issue e registado no log de issues e associado a um responsavel na area de projec-

tos, procedendo-se a uma analise preliminar em termos das suas causas, impacto e possıvel solucao.

Tendo em conta esta analise, e atribuida uma prioridade ao issue e analisada a necessidade de o

escalar para o director DSI. No caso desta organizacao consideramos que a decisao de escalar o is-

sue e tomada tendo em conta a prioridade e o impacto no projecto mas outros criterios podem ser

estabelecidos se considerarmos outra organizacao.

Caso o issue seja escalado para o director DSI, o processo e semelhante tendo apenas em conta

que a responsibilidade da sua execucao e do director DSI, que apos validar a resolucao do issue deve

comunica-lo a area de projectos, sendo esta a responsavel por realizar o seu fecho no log de issues.

Caso o issue nao seja escalado, como apresentado na figura 4.11, a area de projectos realiza o

seu diagostico, identiticando o conjunto de medidas necessarias a sua resolucao e respectiva analise

de calendario e orcamento dessas medidas. Tendo em conta o conjunto de medidas identificadas, sao

52

Figura 4.10: Fluxo do processo de identificacao e gestao de issues escalados.

seleccionadas as medidas a aplicar com possıveis alteracoes ao plano de projecto. Uma das medidas

de tratamento do issue pode ser inclusive a realizacao de um pedido de alteracao, sendo iniciado o

processo de gestao de alteracoes. As medidas seleccionadas sao aplicadas e testadas, sendo validada

a resolucao do issue ou identificada a necessidade de aplicacao de mais medidas de tratamento.

Figura 4.11: Fluxo do processo de gestao de issues nao-escalados e fecho do issue.

4.4.1.5 Gestao de Alteracoes do Projecto

Durante o planeamento e implementacao do projecto surgem alteracoes de ambito propostas pelos

stakeholders, com a apresentacao de novos requisitos ou alteracoes a requisitos ja existentes. Estas

alteracoes irao ter impacto em todo o planeamento do projecto ja realizado, especialmente em termos

de orcamento e calendario. E por isso necessario a orgnizacao garantir a posse de um processo para

a gestao de alteracoes de projecto.

Quando uma nova alteracao e identificada, e registada no log de alteracoes e identificado um re-

sponsavel para a sua gestao dentro da equipa de projecto. E ainda definido o ambito da alteracao, com

a identificacao dos respectivos requisitos e atribuicao de uma prioridade a mesma tendo em conta a sua

importancia no projecto. De forma a alinhar a analise da alteracao com os elementos responsaveis pela

53

implementacao do projecto, e feito um pedido de analise da alteracao ao parceiro relativo a questoes

tecnicas, de orcamento e de calendario. Apos a recepcao da analise do parceiro, a equipa de pro-

jecto procede a uma avaliacao da analise do parceiro e classifica a alteracao como minor ou major de

acordo com os criterios de classificacao da alteracao da organizacao. Esta classificacao esta muitas

vezes associada ao impacto no orcamento e calendario do projecto, embora outros criterios possam

ser considerados.

Caso a alteracao seja classificada como major, tera de ser realizada uma revisao do forecast do

orcamento do projecto por parte da area de planeamento e controlo, de forma a avaliar o impacto no

orcamento do projecto. Este impacto sera avaliado tambem pelo director DSI, o qual tomara a decisao

de aprovacao ou rejeicao do pedido de alteracao. Todo o processo de revisao nao sera detalhado,

tendo em conta que e intrınseco a organizacao e orientado a aspectos da sua governacao. A decisao

de aprovacao da alteracao possui um conjunto de variacoes que necessitariam de ser exploradas em

detalhe caso considerassemos abordar este tema. Tendo em conta que a alteracao ira ter impacto

no orcamento e todo o projecto e interno a organizacao, poderia ser necessario, por exemplo, rever

todo o orcamento do projecto e inclusive requisitar uma alocacao de verbas ao projecto por parte da

organizacao de forma a fazer face a implementacao da alteracao. Assim, considera-se apenas que o

pedido de aprovacao da alteracao e realizado pela area de projectos a area de planeamento e controlo

que, em parceria com o director DSI, toma a decisao de aprovacao ou rejeicao do pedido de alteracao.

O fluxo do processo ate esta fase e apresentado na figura 4.12.

Figura 4.12: Fluxo do processo de gestao de alteracoes relativo ao planeamento e aprovacao daalteracao.

Caso o pedido de alteracao seja aprovado, e dada continuidade ao planeamento da alteracao, com

a revisao da sua prioridade e de calendario, culminando no agendamento da alteracao. O controlo

da alteracao foca-se na contınua monitorizacao do progresso da implementacao da alteracao, com

controlo de orcamento, calendario e ambito. Terminada a implementacao, e apos possıveis pedidos

de pequenas correccoes por parte da area de negocio, e feita a aceitacao da alteracao com a area de

negocio, procedendo-se ao fecho da alteracao no log de alteracoes. O fluxo do processo de controlo e

54

fecho da alteracao e apresentado na figura 4.13.

Figura 4.13: Fluxo do processo de gestao de alteracoes relativo ao controlo e fecho da alteracao.


Relativamente a vista de responsabilidades da fase de implementacao e controlo, o principal interve-

niente e a area de projectos, que executa grande parte das actividades e e responsavel pelo controlo

do seu progresso. Na gestao de riscos esta area colabora com o negocio e parceiro na identificacao e

analise do risco, consultando-a tambem no levantamento e aplicacao de medidas de tratamento.

O parceiro possui uma grande importancia neste processo, na medida em que e o responsavel

pela implementacao do projecto, sendo um dos intervenientes que ira sentir de forma directa as con-

sequencias dos riscos. Por essa razao, deve ser envolvido em todo o processo de identificacao e

tratamento, sendo muitas vezes ele o proprio responsavel pela aplicacao das medidas de tratamento. A

area de negocio, por sua vez, podera ver os seus objectivos e interesses no projecto postos em causa

pelas consequencias dos riscos identificados, sendo necessaria a sua consulta em todo o processo,

especialmente na identificacao e seleccao das medidas de tratamento.

Em termos da gestao de alteracoes, a vista de responsabilidades assume um padrao semelhante

a gestao de riscos, embora neste caso o papel do parceiro seja ainda mais importante, na medida

em que e a entidade que realiza a analise da alteracao e a sua implementacao, estando directamente

envolvido em todo o processo e disponibilizando todo o feedback necessario ao controlo da alteracao.

A area de negocio possui um papel mais passivo neste processo, sendo responsavel pela identificacao

da alteracao e pela sua aceitacao final.

A gestao de issues possui um caracter volatil, podendo um issue ter origem num conjunto de

situacoes ocorridas durante a implementacao do projecto que nao se encontram bem definidas no

seu planeamento. Por essa mesma razao, a definicao de responsabilidades tambem e relativamente

generica, sendo a area de projectos a principal entidade responsavel pela execucao e controlo de pro-

gresso, embora no caso de necessidade de escalar um issue para o director DSI, a responsabilidade de

execucao e controlo de progresso das actividades seja da responsabilidade deste. O parceiro encontra-

se tambem envolvido em todo o processo, sendo consultado na identificacao, analise e resolucao do

55

issue, pelo facto de ser a entidade directamente ligada com a sua ocorrencia e o responavel, muitas

vezes, pela aplicacao concreta das medidas de resolucao.

A vista de responsabilidades relativa aos processos de controlo semanal e mensal do projecto e

detalhada na tabela 4.12. Importa destacar a diferente atribuicao de responsabilidades no controlo

semanal e mensal do projecto, directamente relacionado com os caracteres operacional e estrategico

destas actividades, respectivamente.

No controlo semanal de projecto a area de projectos e responsavel pela execucao e controlo de

progresso de todas as actividades, actuando em colaboracao sobretudo com o parceiro e com a area

de negocio, sendo estes consultados para a identificacao de riscos, issues e alteracoes, controlo de

calendario e orcamento e verificacao do cumprimento dos planos de gestao de stakeholders e de

comunicacoes. Estas actividades teem como objectivo assegurar um controlo de projecto de curto

prazo, garantindo que o planeamento realizado na fase de planeamento e cumprido.

Em termos de controlo mensal do projecto, todas as areas consideradas nesta vista sao envolvidas

nas actividades de controlo, sendo feito um controlo de projecto a longo prazo e inclusive revistos

os planos de gestao de comunicacoes e de stakeholders. Sao tambem elaborados os forecasts de

orcamento e revistas as milestones contratuais, informacoes sobre as quais todas as areas possuem

conhecimento e interesse. Nesta fase os riscos de maior prioridade tambem sao geridos.


DSIParceiro Negocio

GPM-SE1 - Controlo semanal do projecto

GPM-SE1.1 X/P C I A

GPM-SE1.2 X/P A C C

GPM-SE1.3 X/P I

GPM-SE1.4 X/P A A C C

GPM-SE1.5 X/P A C C

GPM-SE1.6 X/P C C

GPM-SE1.7 X/P I C I

GPM-SE1.8 X/P C A

GPM-SE1.9 X/P C C C C

GPM-SE1.10 X/P I C C

GPM-SE1.11 X/P A A A A A

GPM-ME1 - Controlo mensal do projecto

GPM-ME1.1 X/P A A C C C

GPM-ME1.2 X/P C A

GPM-ME1.3 X/P A C C C

GPM-ME1.4 X/P C C C

GPM-ME1.5 X/P C C C C C

GPM-ME1.6 X/P C C C C

GPM-ME1.7 X/P I I I I I

GPM-ME1.8 X/P C C A C

Tabela 4.12: Vista de responsabilidades dos processos de controlo semanal e mensal do projecto.

56


Os principais documentos de suporte do processo na fase de implementacao e iontrolo, alem do plano

de gestao de projecto que acompanha todas as fases do processo, sao os logs que resultam dos

processos de gestao de alteracoes e gestao de issues, o forecast de orcamento e os relatorios de

progresso semanais e mensais. O log de alteracoes possui um conjunto de registos de pedidos de

alteracao, sendo que cada registo reune todas as informacoes de identificacao, analise e planeamento

da alteracao. De forma semelhante, o log de issues reune toda a informacao de identificacao, plane-

mento e resolucao de cada issue do projecto.

O orcamento do projecto, definido na fase de planeamento e constante do plano de gestao de

custos, define a baseline do orcamento do projecto. Porem, ao longo da execucao de projectos, um

conjunto de acontecimentos leva a sua alteracao, sendo raras as excepcoes em que o orcamento do

projecto mantem-se inalterado ate ao seu encerramento. Assim, de forma a fazer face a alteracoes

de orcamento, todos os meses e produzido o forecast de orcamento de projecto que apresenta uma

estimativa do orcamento do projecto ate ao seu encerramento, considerando todas as actividades real-

izadas ate ao momento.

O relatorio de progresso semanal do projecto resulta das actividades de controlo semanal e tem

como objectivo fornecer a informacao de progresso de projecto ao director DSI, sendo apresentadas,

entre outras informacoes, as actividades realizadas durante a semana e as planeadas para a semana

seguinte. O relatorio de progresso mensal do projecto resulta das actividades de controlo mensal,

apresentando um resumo da informacao do conjunto dos relatorios semanais do mes. Entre outras

informacoes, apresenta um resumo do trabalho realizado durante o mes, o forecast de orcamento e

o planeamento de calendario do projecto. Este relatorio e enviado aos elementos da direccao dos

sistemas de informacao e a area de negocio, embora a informacao constante do mesmo seja adaptada

consoante o destinatario. Na tabela A.3 do anexo A.3 sao apresentados em detalhe estes documentos

de suporte.

Em termos da matriz CRUF dos documentos de suporte da fase de implementacao e controlo, esta

encontra-se dividida no cojunto de processos individuais identificados nesta fase, sendo detalhada a

matriz para os processos de controlo semanal e mensal do projecto e para o processo de gestao de

risco, de acordo com as vistas de processos e de responsabilidades apresentadas.

Relativamente a matriz CRUF da gestao semanal do projecto, apresentada na figura 4.13, importa

destacar as interaccoes apenas de consulta relativas a todos os planos de gestao indiviuais, sendo

apenas o plano de gestao de projecto alterado tendo em conta a definicao de actividades com impacto

no calendario do projecto e o controlo de orcamento realizado, com impacto no forecast de orcamento.

Os logs de riscos, alteracoes e issues de projecto tambem sao actualizados tendo em conta que o seu

controlo podera introduzir novas alteracoes e actualizacoes.

Comparando com a anterior, a matriz CRUF do processo de gestao mensal do projecto, apresentada

na tabela 4.14, distingue-se em termos das interacoes de actualizacao dos planos de gestao individuais

considerados, sendo actualizados, entre outros, os planos de gestao de comunicacoes e de gestao de

stakeholders. Estas alteracoes pretendem adequar de melhor forma os respectivos planos ao estado

57

Documentos de suporte Projectos O&M P&C Director

DSIParceiro Negocio

GPM-SE - Gestao semanal do projecto

Plano de gestao de projecto R/U

Registo de stakeholders R

Plano de gestao de stakeholders R

Log de riscos R/U

Plano de gestao de riscos R

Plano de gestao de comunicacoes R

Plano de gestao de custos R

Plano de gestao de calendario R

Relatorio de progresso semanal C/R/U R R

Log de alteracoes R/U

Log de issues R/U

Tabela 4.13: Matriz CRUF dos documentos de suporte do processo de gestao semanal do projecto.

actual de progresso do projecto. E tambem considerada a criacao do forecast de orcamento de projecto

todos os meses, embora este seja desenvolvido a partir do forecast de orcamento do mes anterior de

acordo com as novas estimativas de orcamento do projecto, bem como do conjunto de analises de

orcamento semanais.


DSIParceiro Negocio

GPM-ME - Gestao mensal do projecto

Forecast do orcamento do projecto C

Plano de gestao de projecto R/U

Plano de gestao de Stakeholders R/U

Plano de gestao de riscos R/U

Plano de gestao de comunicacoes R/U

Plano de gestao de custos R/U

Plano de gestao de calendario R/U

Relatorio de progresso mensal C/U R R R R

Registo de stakeholders R/U

Log de riscos R/U

Log de alteracoes R/U

Tabela 4.14: Matriz CRUF dos documentos de suporte do processo de gestao mensal do projecto.

Relativamente a matriz CRUF dos documentos de suporte do processo de gestao de risco, apre-

sentada na tabela 4.15, os unicos documentos de suporte considerados neste processo sao o plano de

gestao de riscos e o log de riscos, sendo que o primeiro e apenas consultado pela area de projectos

enquanto o segundo e actualizado de acordo com os novos riscos identificados.

58


DSIParceiro Negocio

GPM-RI - Gestao de riscos do projecto

Plano de Gestao de Riscos R

Log de Riscos R/U

Tabela 4.15: Matriz CRUF dos documentos de suporte do processo de gestao de riscos do projecto.

4.5 Fase de Handover

Na fase de handover e feita a revisao dos entregaveis do parceiro de acordo com especificacoes

tecnicas e testes de sistema executados pela area de projectos. E feita tambem a aceitacao com a

area de negocio para a aceitacao final do projecto e preparada a entrega do mesmo a area de O&M,

que sera responsavel pelo projecto a partir desta fase. A area de O&M sera ja responsavel pela pas-

sagem do projecto em ambiente de qualidade para ambiente de producao, apos a qual e realizado o

encerramento do projecto e terminado todo o fluxo do processo.


Apos a entrega da implementacao do projecto pelo parceiro a area de projectos, e necessario realizar

um conjunto de actividades de preparacao da aceitacao do projecto por parte da area de negocio

e tambem da area de O&M, apresentadas no fluxo do processo identificado na figura 4.14. Numa

primeira fase, e realizada a preparacao e a passagem do projecto para ambiente de qualidade, um

ambiente de execucao do projecto destinado a realizacao dos testes de aceitacao. E revista toda a

especificacao tecnica e realizados testes de sistema, com eventuais pedidos de correccao da area de

projectos ao parceiro. E tambem realizado o planeamento dos testes de aceitacao da area de negocio,

com a definicao do calendario, plano de testes e recursos necessarios, sendo estes realizados apos a

aceitacao dos testes de sistema pela area de projectos.

Apos aprovacao dos testes sistema, e realizada a aceitacao com o negocio, com a realizacao dos

testes de aceitacao. Caso os testes sejam realizados com sucesso, e feita a aceitacao do projecto

por parte da area de negocio e da area de projectos, assinando as duas o auto de aceitacao. Para a

aceitacao definitiva do projecto, e ainda necessario proceder a aceitacao por parte da area de O&M.

Esta aceitacao, por vezes nao considerada pelas organizacoes, foi considerada tendo em conta que

sera esta a area que ira lidar, no futuro, com eventuais pedidos de manutencao, sendo necessario

garantir que, alem de possuir todo o conhecimento necessario para gerir estes pedidos, o projecto

foi-lhe entregue de acordo com todo o planeamento e requisitos estabelecidos.

Na realizacao do plano de handover a manutencao, toda a documentacao do projecto e compilada

pela area de projectos para entrega a area de O&M, que prepara o ambiente de producao do projecto de

acordo com um conjunto de configuracoes disponibilizadas pela area de projectos e pelo parceiro. Sao

ainda realizados testes de aceitacao pela area de O&M, cuja extensao e complexidade sao definidas

de acordo com o ambito do projecto. Apos a aprovacao dos testes de aceitacao, e ainda necessario

59

Figura 4.14: Fluxo do processo relativo a aceitacao do projecto.

receber e aceitar os logs de riscos, issues e alteracoes do projecto, de forma a esta area possuir toda a

a informacao relativa a pedidos de alteracoes e problemas resolvidos durante a execucao do projecto e

nao previstos no plano de projecto. A aceitacao do projecto e consumada com a aceitacao por parte da

area de O&M e com a assinatura do auto de aceitacao pela mesma. A partir deste momento, o projecto

passa a ser da sua responsabilidade. As actividades detalhadas relativas a aceitacao do projecto pela

area de projectos, negocio e O&M sao apresentadas na tabela 4.16.

Apos a aceitacao do projecto e enviado o pedido de entrada em producao, sendo necessario realizar

a passagem do projecto para ambiente de producao, com a revisao de pedidos de alteracoes, issues e

riscos em ambiente de qualidade. Caso nao exista qualquer tipo de correccao ou alteracao a realizar,

e feita a passagem do projecto para ambiente de producao. Apos o projecto se encontrar em ambiente

de producao, e realizado o seu encerramento. A passagem a producao e comunicada a area de pro-

jectos, que inicia o encerramento do projecto em duas fases: o encerramento tecnico e o encerramento

administrativo.

Apos terminada a passagem do projecto a producao, realizada pela area de O&M e comunicada

formalmente a area de projectos, o encerramento do projecto e iniciado com o envio do pedido de

encerramento administrativo do projecto a area de planeamento e controlo, de forma a iniciar o conjunto

de actividades de fecho do contracto de implementacao realizado com o parceiro e de encerramento

do orcamento e do plano de pagamentos.

Apos ser feito o pedido de encerramento administrativo, a propria area de projectos da inıcio ao

encerramento tecnico, no qual e compilada e arquivada a ultima versao do plano de gestao de projecto,

coleccionadas as licoes aprendidas, elaborado o relatorio de fecho do projecto e realizada uma reuniao

de fecho com as areas de projectos e O&M, juntamente com a area de planeamento e controlo e com

a area de negocio, apos a qual sao libertados os recursos do projecto. O fluxo do processo relativo a

passagem a ambiente de producao e encerramento do projecto e apresentado na figura 4.15.

Apos esta fase, o projecto encontra-se encerrado e a area de O&M munida de toda a informacao

60

Actividades

GPM-HA1 – Revisao da entrega do parceiro – Revisao por parte da equipa de projectos dos entregaveis do parceiro,com a passagem para ambiente de qualidade, revisao da especificacao tecnica, planeamento dos testes de aceitacaoe execucao de testes sistema ao projecto.

GPM-HA1.1 – Preparacao do ambiente de qualidade com o auxılio do parceiro para a execucao de testes de sistema e testesde aceitacao.

GPM-HA1.2 – Passagem do projecto para ambiente de qualidade sob a supervisao do parceiro.

GPM-HA1.3 – Revisao da especificacao tecnica e ajuste de detalhes/decisoes de implementacao com possıveis pedidos decorreccao/alteracao.

GPM-HA1.4 – Planeamento dos testes de aceitacao, com a definicao do plano de testes (calendario, recursos necessarios,responsaveis e testes de aceitacao).

GPM-HA1.5 – Execucao de testes de sistema do projecto.

GPM-HA1.6 – Aceitacao dos testes de sistema do projecto.

GPM-HA2 – Testes de aceitacao com a area de negocio – Execucao dos testes de aceitacao com a area de negociopara a aceitacao final do projecto.

GPM-HA2.1 – Execucao dos testes de aceitacao pela area de negocio.

GPM-HA2.2 – Aprovacao dos testes de aceitacao.

GPM-HA2.3 – Formalizacao da aceitacao do projecto pela area de negocio com a assinatura do auto de aceitacao.

GPM-HA2.4 – Aceitacao do projecto pela area de projectos com a assinatura do auto de aceitacao por parte da area deprojectos.

GPM-HA3 – Realizacao do plano de handover a area de O&M – Preparacao do handover do projecto a area de O&Mcom passagem de documentacao, preparacao de ambientes e aceitacao de logs de riscos, issues e alteracoes quepassam a ser responsabilidade da area de O&M.

GPM-HA3.1 – Compilacao e passagem de documentacao tecnica e de gestao do projecto.

GPM-HA3.2 – Preparacao dos ambientes de producao pela area de O&M de acordo com as configuracoes disponibilizadaspela area de projectos e pelo parceiro.

GPM-HA3.3 – Execucao dos testes de aceitacao da area de O&M para inıcio do handover.

GPM-HA3.4 – Aprovacao dos testes de aceitacao pela area de O&M.

GPM-HA3.5 - Aceitacao de log de riscos.

GPM-HA3.6 - Aceitacao de log de issues.

GPM-HA3.7 - Aceitacao de log de alteracoes.

GPM-HA3.8 – Formalizacao do handover do projecto com a producao e assinatura do documento de handover e do auto deaceitacao;

Tabela 4.16: Actividades detalhadas de aceitacao do projecto.

necessaria para lidar com futuros pedidos de manutencao que possam surgir, garantindo que nao

existirao questoes em aberto a tratar com recursos da area de projectos, que nessa fase se encontrarao

alocados a outros projectos e ja sem capacidade para enderecar este tipo de questoes.


A vista de responsabilidades da fase de handover possui um interesse especial nesta arquitectura na

medida em que define de que forma e feita a transicao do projecto da area de projectos para a area

de O&M, a qual ira passar a ser responsavel pelo mesmo. Alem disso, e tambem nesta fase que a

participacao do parceiro no projecto, responsavel pela sua implementacao, termina com a aceitacao do

projecto.

Na revisao da entrega do parceiro, a area de projectos e responsavel pela realizacao de todas

61

Figura 4.15: Fluxo do processo relativo a passagem a producao e encerramento do projecto.

as actividades em estrita colaboracao com o parceiro, nomeadamente na preparacao e passagem do

projecto para ambiente de qualidade que, embora realizada pela area de projectos, necessita de apoio

por parte do parceiro. Dependendo da complexidade do projecto, podera variar de uma actividade

de simples supervisao ate a partilha de responsabilidades na sua execucao. Apos a passagem a

ambiente de qualidade, embora o parceiro seja consultado num conjunto de outras actividades, as suas

responsabilidades diminuem ate a sua saıda no encerramento do projecto.

A situacao da area de O&M e inversa a do parceiro, tendo em conta que o conjunto de respons-

abilidades da mesma aumenta a partir da realizacao do plano de handover, onde a area de projectos

e responsavel apenas pela passagem da documentacao e pelo inıcio do processo de passagem de

conhecimento e responsabilidades. A area de O&M aceita todos os logs do projecto, entregues pela

area de projectos e formaliza o handover com a assinatura do auto de aceitacao, garantindo assim es-

tar na posse de toda a informacao necessaria para gerir futuros pedidos de manutencao. A passagem

do projecto para ambiente de producao e ja realizada pela area de O&M, com a consulta da area de

projectos e do parceiro para resolucao de eventuais questoes que possam surgir.

Nas actividades de aceitacao do projecto, a area de negocio desempenha o principal papel com a

aprovacao dos testes de aceitacao do projecto, na medida em que correspondem ao principal stake-

holder do projecto e a origem do mesmo. A area de projectos aceita a implementacao do projecto pelo

62

parceiro e a area de O&M aceita o handover do projecto feito pela area de projectos, ja depois de aceite

pela area de negocio. As responsabilidades relativas a aceitacao do projecto encontram-se detalhadas

na tabela 4.17.


DSIParceiro Negocio

GPM-HA - Revisao da entrega do parceiro

GPM-HA1.1 X/P C C

GPM-HA1.2 X/P I C I

GPM-HA1.3 X/P A C

GPM-HA1.4 X/P I I I C

GPM-HA1.5 X/P I C

GPM-HA1.6 X/P/D d C I

GPM-HA2 - Testes de aceitacao com a area de negocio

GPM-HA2.1 X/P I I C

GPM-HA2.2 X/P/d I I D

GPM-HA2.3 X/P I I I I C

GPM-HA2.4 X/P/d I D I

GPM-HA3 - Realizacao do plano de handover a manutencao

GPM-HA3.1 X/P C C

GPM-HA3.2 P X I C

GPM-HA3.3 P X I I

GPM-HA3.4 P X/d D I

GPM-HA3.5 P X/d D I

GPM-HA3.6 P X/d D I

GPM-HA3.7 P X/d D I

GPM-HA3.8 P X I I I

Tabela 4.17: Vista de responsabilidades das actividades de aceitacao do projecto.

O encerramento do projecto e da responsabilidade das areas de projectos e de planeamento e

controlo pelo facto de serem as areas que acompanharam todo o projecto e que desempenharam

as principais actividades, estando a partir deste momento desalocadas de actividades do projecto. A

area de projectos realiza o encerramento tecnico, com a compilacao da informacao mais relacionada

com a gestao do projecto, e a area de planeamento e controlo realiza o encerramento administrativo,

directamente ligado com o encerramento de contractos, orcamento e plano de pagamentos.


Relativamente a vista de informacao da fase de handover, importa destacar dois dos documentos de

suporte provenientes desta fase, o auto de aceitacao e o documento de handover. O auto de aceitacao

reune toda a informacao relativa ao processo de aceitacao do projecto, reunindo os logs de projecto e

os testes de aceitacao realizados. E produzido pela area de projectos e assinado por esta em conjunto

com a area de O&M e a area de negocio. O documento de handover formaliza a passagem do projecto

63

da area de projectos para a area de O&M, apresentando, entre outra informacao que a organizacao

considere relevante, os logs do projecto aceites pela area e os responsaveis pela sua aceitacao.

No encerramento do projecto sao ainda definidos o relatorio de fecho do projecto, que compila um

conjunto de documentacao relativa ao encerramento do projecto, e as licoes aprendidas, documento

que resulta do feedback dos varios intervenientes em todo o processo de gestao do projecto juntamente

com a experiencia adquirida pelo gestor de projecto. O conjunto de documentos de suporte relativos a

fase de handover sao detalhados na tabela A.4 do anexo A.4.

Em termos da matriz CRUF da fase de handover, apresentada na tabela 4.18, destaca-se a criacao

dos documentos de suporte relativos a esta fase e a actualizacao e fecho do plano de gestao de pro-

jecto, dos logs de riscos, issues e alteracoes e do contracto de compra. O fecho dos restantes doc-

umentos, pertencentes apenas a fase de handover nao foi considerado tendo em conta o seu curto

ciclo de vida e osbjectivos especıficos a que sao aplicados. E ainda possıvel destacar o conjunto de

interacoes de actualizacao relativas ao relatorio de fecho de projecto e das licoes aprendidas, docu-

mentos que resultam do feedback e da informacao manipulada por um conjunto de areas da direccao

dos sistemas de informacao.

Documentos de suporte Projectos O&M P&C Compras Director

DSIParceiro Negocio

Plano de gestao de projecto R/U/F R/U R R

Log de riscos R/U R/U/F

Log de issues R/U R/U/F

Log de alteracoes R/U R/U/F

Auto de aceitacao C/R/U R/U R R/U

Documento de handover C/R/U R/U R

Relatorio de fecho de projecto C/U R/U R/U R/U R/U

Licoes aprendidas C/U R/U R/U R/U R/U

Contracto de compra R/U/F R

Tabela 4.18: Matriz CRUF dos documentos de suporte da fase de handover do processo.

64

Capıtulo 5

Avaliacao

Neste capıtulo e apresentada a avaliacao da arquitectura de processos, de acordo com a fase de

avaliacao do DSRM. Tendo em conta o conjunto de questoes identificadas na definicao do problema

como guias para o desenvolvimento desta arquitectura, e apresentado um conjunto de resultados que

vai ao encontro da resposta a essas questoes:

1. Questao 1 - Que processos (e correspondentes actividades) devem ser executados para a gestao

de pedidos de execucao de projectos e manutencoes?

A arquitectura de processos desenvolvida, dividida nas fases de oportunidade, de planeamento,

de implementacao e controlo e de handover, de acordo com o ciclo de vida dos projectos consid-

erado, apresenta o conjunto de actividades a realizar por uma direccao de sistemas de informacao

de forma a gerir pedidos de projectos e manutencoes que lhe sao propostos.

A vista de processos de cada uma das fases apresenta o fluxo do processo, identificando ainda

um conjunto de actividades detalhadas a executar em cada macro-actividade. O conjunto das

vistas de processos desta arquitectura cobre todo o ciclo de vida de um pedido de projecto, desde

a sua classificacao ate a entrega do projecto a area de negocio, passando pelo seu planeamento

e controlo. Relativamente a pedidos de manutencao, estes podem ser integrados em servicos de

manutencao, cuja implementacao e realizada externamente por um parceiro, ou agendados para

manutencao interna, assumindo-se que toda a sua posterior gestao sera realizada de acordo com

um processo ja definido na organizacao.

Todo o desenho foi realizado a partir dum caso real de uma organizacao, de forma a permitir

uma visao mais detalhada do problema e de possıveis solucoes bem como ter consciencia dos

aspectos mais crıticos na gestao dos pedidos em casos reais. Apesar de baseada num caso

real, a arquitectura apresentada neste documento generaliza aspectos do processo intrınsecos a

organizacao, mantendo-se apenas as actividades genericas passıveis de serem adoptadas por

qualquer direccao de sistemas de informacao que esteja alinhada com os constrangimentos ap-

resentados pelo problema considerado.

65

2. Questao 2 - Quais as responsabilidades dos varios elementos da direccao dos sistemas de

informacao em todo o processo?

De acordo com a estrutura organizacional considerada no caso real, foram definidas, para cada

actividade detalhada na vista de processos, um conjunto de responsabilidades dos intervenientes

do processo, pertencentes a direccao dos sistemas de informacao. Esta definicao de responsabil-

idades foi realizada, numa primeira fase, de acordo com a actual definicao de responsabilidades

na organizacao, sendo posteriormente analisada e alinhada com a vista de processos definida e

proposto um conjunto de alteracoes as responsabilidades incialmente definidas.

Todas as alteracoes foram revistas e aprovadas em reunioes de validacao com os stakeholders

de forma a garantir que a definicao de responsabilidades se encontra tanto alinhada com a vista

de processsos como com os intervenientes em todo o processo. Apesar de algumas referencias

analisadas no capıtulo 2 apresentarem abordagens a definicao de responsabilidades, todo o tra-

balho apresentado nesta vista foi realizado originalmente.

3. Questao 3 - Quais os documentos que suportam todo o processo?

A vista de informacao agrega um conjunto de documentos de suporte ao processo, detalhando-os

de acordo com a informacao que disponibilizam e com os seus objectivos. Sao definidos os princi-

pais documentos de suporte considerados no processo, inicialmente identificados de acordo com

as referencias analisadas no capıtulo 2 e mais tarde adicionados e adaptados novos documentos

de acordo com as necessidades da vista de processos.

De forma a integrar esta vista com as anteriores, foi proposta e validada uma definicao de matriz

CRUF dos documentos de suporte, que para cada documento apresenta o conjunto de interacoes

realizadas pelos intervenientes do processo.

A solucao foi desenvolvida num espaco de tempo limitado, razao pela qual foi necessario tomar

varias decisoes de desenho, nomeadamente o conjunto de processos a cobrir pela arquitectura. Considerou-

se um conjunto limitado de processos, em detrimento de cobrir todos os apresentados pelas referencias

em menor detalhe, de forma a definir uma arquitectura com relevancia para o problema e que enderece

um conjunto de tematicas que os stakeholders consideram as mais importantes.

Outro objectivo definido para esta arquitectura era a sua conformidade com as melhores praticas

em gestao de projectos e manutencoes de acordo com as referencias consideradas no capıtulo 2.

Dessa forma, durante todo o desenho da arquitectura foram analisados e seleccionados um conjunto

de processos apresentados nas referencias, procedendo-se a algumas adaptacoes de forma a ir ao

encontro dos nossos objectivos.

Tendo em conta o caso real de uma organizacao como ponto base para a definicao desta arquitec-

tura, foi necessario ir ao encontro de todas as expectativas dos stakeholders relativas a arquitectura a

desenhar. Ao longo do processo de desenvolvimento foram realizadas reunioes de validacao da arqui-

tectura com os stakeholders, de forma a garantir a sua satisfacao. Apesar da sua importancia em todas

66

as vistas, foi na vista de responsabilidades que o feedback dos stakeholders foi mais importante pelo

facto de se tratar de trabalho original que nao se encontrava contemplado em nenhuma referencia.

Foi tambem estabelecido como objectivo generalizar aspectos intrınsecos a organizacao, razao pela

qual a arquitectura de processos apresentada neste documento difere da arquitectura desenvolvida

considerando apenas o caso real da organizacao. Aspectos especıficos a organizacao nao foram con-

templados nesta versao da arquitectura, optando-se por nao os detalhar e apresentar apenas a sua

generalizacao. Porem, a arquitectura apresentada obedece a um conjunto de constrangimentos, moti-

vados pela extensao do tema e impossibilidade de cobrir o problema na sua forma mais generica.

5.1 Avaliacao com Stakeholders

Tendo em conta o alinhamento com o caso real de uma organizacao, foi necessario considerar os

principais stakeholders durante o desenho da arquitectura. Foi desenvolvido um documento designado

por manual do processo, que apresenta toda a arquitectura de acordo com os objectivos e as normas

da organizacao, atraves de um processo iterativo, no qual a arquitectura de processos foi avaliada e o

feedback proveniente dessa avaliacao utilizado para a producao de versoes melhoradas da mesma.

Tendo em conta a disponibilidade reduzida dos principais stakeholders desta arquitectura, considerou-

se um representante dos mesmos em todo o processo de avaliacao, que possui um conhecimento

profundo de toda a organica da organizacao e dos objectivos que a mesma procura ver alcancados

na gestao de projectos e manutencoes. Este representante ira ser designado apenas por stakeholder,

tendo em conta que representa o conjunto de todos os stakeholders. Numa primeira fase, foi necessario

interagir directamente com o stakeholder de forma a compreender de que forma a organizacao realiza a

gestao dos pedidos de projectos e manutencoes e quais as actividades actualmente realizadas, identifi-

cando aspectos que nao se encontram devidamente contemplados no processo as-is e que necessitam

de melhorias.

Face a todo o levantamento de informacao realizado e as referencias consideradas, foram definidas

a vista de processos e a vista de informacao das quatro fases, procedendo-se para cada fase a uma

sessao de apresentacao e validacao das vistas. Nestas sessoes foram apresentadas versoes destas

vistas e levantado um conjunto de alteracoes e sugestoes resultantes do feedback do stakeholder.

Apos cada sessao, foi produzida uma nova versao da arquitectura de acordo com o feedback recebido,

sujeita a nova sessao de validacao ate ser aceite pelo stakeholder e tornada a versao final.

Apos a versao final das vistas de processos e de informacao definida, iniciou-se a definicao da vista

de responsabilidades. Para cada fase foi definida uma versao inicial da vista de responsabilidades que

foi depois apresentada, alinhada e validada em sessoes de revisao com o stakeholder. Esta vista foi

aquela que exigiu um maior esforco de desenvolvimento, na medida em que foram necessarias mais

alteracoes e negociacoes de forma a alinha-la tanto com os objectivos de desenho da arquitectura como

com os objectivos do stakeholder.

A arquitectura de processos definida no manual do processo, bem como a versao generalizada

apresentada nesta dissertacao, apresentam assim uma arquitectura que foi alvo de um conjunto de

67

sessoes de avaliacao e validacao com os stakeholders, alcancando-se uma solucao alinhada com os

seus objectivos e com os principais principios de gestao de projectos e manutencoes apresentados

pelas referencias consideradas.

5.2 Mapeamento com Referencias

De acordo com a fase de avaliacao do metodo DSRM aplicado, um dos metodos de avaliacao pro-

postos foi o mapeamento com referencias, que pretende demonstrar de que forma foi garantida a

conformidade da arquitectura de processos com as melhores praticas na area de gestao de projec-

tos e manutencoes. Assim, este metodo estabelece um correspondencia entre os processos definidos

na arquitectura e aqueles que sao identificados no conjunto de referencias analisadas, garantindo a

existencia de evidencias concretas desta conformidade.

5.2.1 Fase de Oportunidade

Em termos da fase de oportunidade, a actividade de identificacao da oportunidade encontra-se apenas

contemplada na ISO 21500 e no PMBOK, embora nao fazendo parte do ambito de nenhuma delas.

Segundo a ISO 21500, as oportunidades devem ser avaliadas de forma a decisao da sua aceitacao ser

suportada e informada. O PMBOK assume apenas a existencia do caso de negocio e do statement

of work nos processos identificados, nao apresentando quaisquer processos para a sua definicao. A

actividade de classificacao de oportunidade e semelhante a de identificacao, sendo apenas considerada

na ISO 21500 como um conjunto de actividades que levam a obtencao de autorizacao para iniciar um

novo projecto, tendo a organizacao de encontrar um elemento responsavel pelo mesmo. Por essa

razao, e nesta fase que e realizada a classificacao da oportunidade em oportunidade de projecto ou de

manutencao, sendo posteriormente entregue a uma das respectivas areas.

Terminada a classificacao da oportunidade, todas as actividades encontram uma correspondencia

com processos identificados tanto na ISO 21500 como no PMBOK. A actividade de analise de opor-

tunidade corresponde as actividades de desenvolvimento do project charter considerada pelas duas

referencias, onde e feita a identificacao das responsabilidades e autoridades do projecto e documen-

tadas as necessidades de negocio, os objectivos a atingir, os entregaveis esperados e os aspectos

economicos do projecto. Como extensao a esta actividade, optou-se ainda por considerar a analise de

calendario e de riscos, aspectos importantes na posterior avaliacao da oportunidade no contexto do

portfolio.

Apos a oportunidade analisada, toda a integracao da oportunidade em portfolio e justificada pela

definicao de gestao de portfolio apresentada pela ISO 21500 e pelo PMBOK, definida como uma gestao

centralizada de um conjunto de projectos e programas em conjunto, de forma a atingir objectivos es-

trategicos. A definicao de prioridade, orcamento e calendario e justificada pela sua relevancia para os

planos estrategicos da organizacao. A integracao em portfolio encontra-se ainda apresentada no CO-

BIT nos processos PO1 - Define a strategic IT plan e PO5 - Manage IT investment, que apresentam a

68

analise de portfolios de projectos e servicos e a manutencao do portfolio de projectos, respectivamente.

Em termos da analise de oportunidades de manutencao e integracao em portfolio de servicos,

realizou-se uma correspondencia directa com as oportunidades de projecto, sendo identificadas as

mesmas referencias. Relativamente ao planeamento da manutencao, o trabalho realizado foi sobre-

tudo original considerando o caso real da organizacao.

Os processos identificados pela ISO/IEC 14764, orientada a processos de manutencao, tambem

poderiam ter sido considerados como referencia. Porem, esta referencia possui um caracter mais op-

eracional, optando-se por manter o processo de identificacao da oportunidade de manutencao generico

e semelhante ao das oportunidades de projecto. Na tabela 5.1 e apresentada o mapeamento com re-

ferencias relativo a fase de oportunidade.

Actividades ISO 21500 PMBOK COBIT ITIL ISO 31000

GPM-OP1 - Identificacao da oportunidade

GPM-OP2 - Classificacao da oportunidade

GPM-OP3 - Analise da oportunidade de projecto

GPM-OP4 - Integracao em portfolio de projectos

GPM-OP5 - Analise da Oportunidade de manutencao

GPM-OP6 - Planeamento da manutencao evolutiva

GPM-OP7 - Integracao em portfolio de servicos de manutencao

Tabela 5.1: Mapeamento com referencias relativo a fase de oportunidade.

5.2.2 Fase de Planeamento

A ISO 21500 apresenta um grupo de processos referentes a esta fase, identificando processo utiliza-

dos para desenvolver todo o detalhe do planeamento do projecto, sendo suficiente para definir todas as

baselines de gestao sobre as quais o mesmo ira ser desenvolvido. O PMBOK apresenta o planeamento

do projecto como o processo de definicao, preparacao e coordenacao de um conjunto de planos sub-

sidiarios e individuais a serem integrados num plano de gestao de projecto. O COBIT por sua vez define

o processo PO10 - Manage Projects que reune um conjunto de actividades necessarias a definicao do

plano de gestao de projecto.

A revisao do plano de gestao de projecto e justificada no PMBOK e na ISO 21500 com a utilizacao

dos documento de suporte da fase de oportunidade (statement of work, project charter e caso de

negocio) como inputs para a definicao do plano de gestao de projecto, sendo necessario rever toda a

informacao constante nestes documentos. Estas referencias consideram ainda como input do plano de

gestao de projecto todos os planos de gestao individuais definidos ao longo da fase, razao pela qual

tambem existe uma revisao do plano de projecto no final da fase de planeamento, com o objectivo de

rever todos os planos indiviuais e dar inıcio a implementacao do projecto.

As duas revisoes do plano de gestao do projecto sao ainda justificadas pelo COBIT, que apresenta

a necessidade de revisao e aceitacao de todos os entregaveis da fase anterior para aprovacao de

entrada numa nova fase do projecto. Assim, no inıcio da fase de planeamento e necessario rever toda

69

a informacao recolhida durante a fase de oportunidade e no final da fase garantir que todos os planos

desenvolvidos se encontram devidamente definidos para inıcio da implementacao do projecto.

O PMBOK e a ISO 21500 apresentam a identificacao de stakeholders como um processo inicial a

considerar na gestao dos mesmos. Em termos de definicao do plano de gestao de stakeholders, a ISO

21500, ao contrario do PMBOK, nao considera a definicao de um plano de gestao individual, apresen-

tando apenas um processo dividido em duas fases, a fase de planeamento e a fase de implementacao

e controlo, esta ultima com o objectivo de controlar e monitorizar as expectativas dos stakeholders.

Optou-se, a imagem do que e apresentado pelo PMBOK, manter o plano de gestao de stakeholders

individualmente, de forma a englobar toda a informacao relativa a sua gestao. O COBIT tambem apre-

senta actividades orientadas a garantia de participacao dos stakeholders na definicao e execucao do

projecto.

Em termos de gestao de risco, a ISO 21500 e o PMBOK apresentam abordagens semelhantes com

a definicao do plano de gestao de riscos. Porem, a gestao de risco e vista como um processo vital na

organizacao pelos principais stakeholders, com consequencias graves em situacoes onde os riscos nao

sao devidamente controlados. Por essa mesma razao, considerou-se tambem a norma internacional

orientada a gestao de risco, a ISO 31000, que alem de apresentar a definicao do plano de gestao de

risco identifica tambem actividades detalhadas relativamente ao tratamento e controlo de riscos. O

COBIT tambem dedica um processo exclusivo a gestao de risco, o PO9 - Assess and Manage Risks.

Em termos de gestao de risco, a principal referencia e a ISO 31000, sendo tambem considerado o

PMBOK e o COBIT.

O planeamento de comunicacoes e justificado pelos processos apresentados pela ISO 21500 e pelo

PMBOK, sendo o ultimo a principal referencia na medida em que apresenta uma grande extensibilidade

nesta area com o processo de planeamento da gestao de comunicacoes. O COBIT apresenta ape-

nas actividades de monitorizacao e comunicacao da performance do projecto, directamente ligadas a

aspectos de comunicacao do projecto.

Em termos de todo o processo de compra, as principais referencias consistem nos processos de

gestao de compras apresentados pea ISO 21500 e pelo PMBOK, a primeira dividindo o processo no

planeamento da compra e na seleccao de parceiros e a segunda no planeamento e no controlo da

compra. O COBIT apresenta tambem um conjunto de referencias uteis no procedimento de compra no

processo AI5 - Procure IT Resources, semelhante aos processsos referidos anteriormente e apresen-

tando um foco na definicao do contracto de compra, com as actividades AI5.2 e AI5.4 de gestao de

contractos com o parceiro e de aquisicao de recursos de tecnologias de informacao, respectivamente.

Relativamente a gestao de custos, a ISO 21500 e o PBMOK correspondem as principais referencias,

a primeira com os processos de estimativa de custos e definicao de orcamento e a segunda com

os processos de desenvolvimento do plano de gestao de custos, estimativa de custos e definicao do

orcamento. Em termos de gestao de calendario, a ISO 21500 apresenta um conjunto de processos

mais operacionais, com o sequenciamento de actividades, a estimativa de duracao dessas actividades

e a definicao do calendario de projecto. Por seu lado, o PMBOK apresenta apenas os processos de

gestao do plano de calendario e de definicao do calendario de projecto. Na tabela 5.2 e apresentado o

70

mapeamento com referencias relativo a fase de Planeamento.


GPM-PL1 - Revisao do planeamento de projecto

GPM-PL2 - Identificacao de stakeholders

GPM-PL3 - Definicao do plano de gestao de stakeholders

GPM-PL4 - Definicao do plano de gestao de riscos

GPM-PL5 - Definicao do Plano de Gestao de Comunicacoes

GPM-PL6 - Planeamento da compra

GPM-PL7 - Consulta ao mercado

GPM-PL8 - Seleccao de proposta

GPM-PL9 - Definicao do contracto de compra

GPM-PL10 - Planeamento de custos do projecto

GPM-PL11 - Planeamento de calendario do projecto

GPM-PL12 - Revisao do plano de gestao de projecto

Tabela 5.2: Mapeamento com referencias relativo a fase de planeamento.

5.2.3 Fase de Implementacao e Controlo

A gestao semanal e mensal do projecto possui as principais referencias na ISO 21500 e no PMBOK,

na medida em que sao apresentados grupos de processos dedicados ao controlo de todo o projecto.

Nenhuma das referencias apresenta a distincao entre o controlo semanal e mensal, apresentando sem

distincao processos de controlo mais operacionais e outros mais estrategicos. A ISO 21500 apresenta

os grupos de processos de implementacao e processos de controlo, estando os primeiros mais ligados

ao controlo semanal com a definicao de actividades a realizar pela equipa durante a semana e o se-

gundo ligado aos controlos semanais e mensais com controlo de orcamento, calendario, comunicacao,

stakeholders, riscos e alteracoes. O PMBOK tambem apresenta um grupo de processos dedicado

ao controlo e monitorizacao do projecto, com processos para a gestao de custos, calendario, riscos,

comunicacoes e stakeholders.

O processo de gestao de alteracoes e identificado na ISO 21500 no processo de controlo de

alteracoes e no PMBOK no processo de controlo integrado de alteracoes. O processo identificado

e identico nas duas referencias, nao apresentando um grande detalhe mas cobrindo todo o ciclo de

vida da alteracao ate ao seu encerramento.

Relativamente a gestao de risco, a principal referencia e a ISO 31000, que apresenta um maior

detalhe neste processo que a ISO 21500 e o PMBOK. A ISO 21500 divide o processo na identficacao,

avaliacao e tratamento dos riscos enquanto que o PMBOK apresenta a identificacao, a analise quan-

titativa e qualitativa do risco e o planeamento das respostas aos riscos. Ja a ISO 31000, apresenta

actividades de identificacao, analise, avaliacao, seleccao de medidas de tratamento e definicao do

plano de tratamento de riscos, apresentando um maior detalhe e coesao entre todas as actividades

apresentadas.

71

A gestao de issues nao e considerada em nenhuma das principais referencias analisadas, considerando-

se por isso o processo para a gestao de incidentes apresentado pelo ITIL para a definicao do processo

de gestao de issues, possuındo um ambito e objectivos semelhantes. Os processos de categorizacao,

prioritizacao, diagostico e escalamento do incidente foram directamente aplicados a analise do issue,

correspondendo o processo de investigacao e diagnostico do incidente ao aplicado no diagnostico do

issue. A resolucao e recuperacao do incidente e o seu fecho foram aplicados na resolucao e fecho do

issue, respectivamente. Na tabela 5.3 e apresentado o mapeamento com referencias relativo a fase de

implementacao e controlo.


GPM-SE - Gestao semanal do projecto

GPM-SE1 - Controlo semanal do projecto

GPM-ME - Gestao mensal do projecto

GPM-ME1 - Controlo mensal do projecto

GPM-AL - Gestao de alteracoes

GPM-AL1 - Definicao de ambito da alteracao

GPM-AL2 - Analise da alteracao

GPM-AL3 - Planeamento da alteracao

GPM-AL4 - Controlo da alteracao

GPM-AL5 - Fecho da alteracao

GPM-RI - Gestao de riscos

GPM-RI1 - Registo do risco

GPM-RI2 - Analise do risco

GPM-RI3 - Identificacao de medidas de tratamento do risco

GPM-RI4 - Seleccao de medidas de tratamento do risco

GPM-RI5 - Definicao do plano de tratamento do risco

GPM-IS - Gestao de issues

GPM-IS1 - Registo do issues

GPM-IS2 - Analise preliminar do issues

GPM-IS3/5 - Diagnostico do issues

GPM-IS4/6 - Resolucao do issues

GPM-IS7 - Fecho do issues

Tabela 5.3: Mapeamento com referencias relativo a fase de implementacao e controlo.

5.2.4 Fase de Handover

A fase de handover possui como principal referencia o COBIT, que cobre todos os aspectos de aceitacao

do projecto, entrega a manutencao, passagem a ambiente de producao e encerramento do projecto. A

ISO 21500 e o PMBOK abordam superficialmente alguns destes aspectos, nomeadamente o encerra-

mento do projecto, sendo importante para complementar os processos apresentados pelo COBIT.

Em termos da revisao da entrega do parceiro e dos testes aceitacao com o negocio, a ISO 21500

apresenta a necessidade de garantir que todos as actividades e entregaveis do projecto foram termi-

72

nados, de forma a assegurar que as varias fases do projecto se encontram completas. Ja o PMBOK

identifica nesta fase a realizacao de actividades de revisao de toda a informacao proveniente de fases

anteriores do projecto e a realizacao de actividades de aceitacao do projecto pelo cliente de forma a

garantir que o projecto reune todos os requisitos para o seu encerramento. Ja o COBIT apresenta

uma abordagem mais fina, apresentando processos de revisao apos a implementacao do projecto, de

planeamento de testes e de execucao de testes de aceitacao final.

Relativamente a realizacao do plano de handover a manutencao e a passagem do projecto para

ambiente de producao, o PMBOK afirma apenas que devem ser realizadas actividades com o objectivo

de transferir os produtos e servicos do projecto para a proxima fase ou para ambiente de producao,

referindo ainda a possibilidade de estes passarem para a area de operacoes e manutencao. O COBIT

apresenta um conjunto de processos para o handover a manutencao, nomeadamente o planeamento

do handover, a transferencia de conhecimento para a area de manutencao e a definicao de procedimen-

tos e tarefas a serem executadas pela area de manutencao de forma a assegurar que esta se encontra

preparada para as tarefas a realizar no futuro. Em termos da passagem do projecto para producao, o

COBIT apresenta um processo dedicado, com a realizacao de actividades que consideramos pertencer

ao processo de planeamento do handover mas tambem com novas actividades relativas a execucao do

projecto em ambiente de producao.

O encerramento tecnico do projecto faz parte das tres principais referencias consideradas nesta

fase, todas elas apresentando a coleccao das licoes aprendidas e o encerramento de todas as activi-

dades de projecto como as principais tarefas a realizar para o seu fecho. O encerramento administrativo

do projecto encontra-se especialmente enderecado pelo PMBOK, que identifica directamente o encer-

ramento das actividades de compra e de todos os contractos estabelecidos, embora se considere estas

actividades parte da actividades de encerramento do projecto identificadas tambem pela ISO 21500 e

pelo COBIT. Na tabela 5.4 e apresentado o mapeamento com referencias relativo a fase de handover.


GPM-HA1 - Revisao da entrega do parceiro

GPM-HA2 - Testes de aceitacao com o negocio

GPM-HA3 - Realizacao do plano de handover a manutencao

GPM-HA4 - Transferencia de ambiente de qualidade para producao

GPM-HA5 - Encerramento tecnico do projecto

GPM-HA6 - Encerramento administrativo do projecto

Tabela 5.4: Mapeamento com referencias relativo a fase de handover.

73

Capıtulo 6

Conclusao e Trabalho Futuro

Neste capıtulo sao apresentadas as principais conclusoes relativas ao trabalho desenvolvido bem como

identificado um conjunto de propostas futuras a desenvolver de forma a dar continuidade a todo o

trabalho realizado.

Este trabalho teve como principal objectivo a definicao de um processo de gestao de pedidos de

projectos e manutencoes nas direccoes de sistemas de informacao, tendo como referencia um caso

real de uma organizacao. Tendo em conta este caso real, foram definidas duas versoes da arquitectura,

uma aplicada ao caso real considerado e apresentada por um manual do processo, e uma versao gen-

eralizada da arquitectura aplicavel a um conjunto de direccoes de sistemas de informacao, apresentada

neste documento.

Considerando as principais referencias na gestao de projectos e manutencoes nas organizacoes,

foram identificados os principais processos a definir para a correcta gestao de pedidos de projectos e

manutencoes, sendo definida uma arquitectura de processos dividida em tres vistas: a vista de proces-

sos, a vista de responsabilidades e a vista de informacao.

A arquitectura desenvolvida foi divida em quatro fases, de acordo com o ciclo de vida dos projectos

considerado. A fase de oportunidade, comum a pedidos de projectos e manutencao, termina com a

integracao da oportunidade num portfolio de projectos ou de servicos de manutencao, podendo tambem

terminar com o agendamento da manutencao, caso se trate de um pedido deste tipo. Apos esta fase,

sao detalhadas as fases de planeamento, de implementacao e controlo e de handover, confinadas a

oportunidades de projecto.

Para cada fase da arquitectura de processos foram definidas a vista de processos, que apresenta

o fluxo do processo em termos de actividades a realizar, a vista de responsabilidades, que identifica

as principais responsabilidades dos intervenientes no processo durante a respectiva fase e a vista de

informacao, que apresenta os principais documentos de suporte da fase do processo. Estas tres vistas,

em conjunto, definem toda a arquitectura de processos para a gestao de pedidos de projectos e de

manutencoes nas direccoes de sistemas de informacao.

A avaliacao da arquitectura foi realizada de acordo com dois metodos propostos e inseridos na

fase de avaliacao do metodo DSRM aplicado. De forma a ir ao encontro do caso real da organizacao

74

considerado, foi conduzida uma avaliacao com stakeholders, de forma a garantir o cumprimento de

um conjunto de requisitos e objectivos dos principais interessados na arquitectura. Tendo em conta

as principais referencias na gestao de projectos e manutencoes, foi tambem considerado o metodo de

mapeamento com referencias, que estabelece um conjunto de correspondencias entre os processos

definidos na arquitectura e aqueles que sao definidos pelas referencias, obtendo-se, para todos os

processos, um conjunto de correspondencias com as referencias consideradas.

A escolha dos processos a incluir na arquitectura foi definida tendo em conta o conjunto de pro-

cessos que iam ao encontro dos interesses dos stakeholders, sendo necessario definir um conjunto de

processos limitado. Processos como a gestao de ambito e a gestao de qualidade nao foram considera-

dos na arquitectura, embora apresentados no conjunto de referencias analisadas, sendo interessante,

no futuro, considerar um conjunto adicional de processos.

As oportunidades de manutencao sao consideradas apenas na fase de oportunidade, a partir da

qual sao integradas em servicos de manutencao ou agendadas para implementacao. Esta decisao

cria uma lacuna na gestao dos pedidos de manutencao posterior a fase de oportunidade, caso a

organizacao nao possua nenhum processo para o efeito. Esta decisao foi tomada de acordo com

o nıvel de granularidade pretendido para a arquitectura, considerando-se a gestao dos pedidos de

manutencao a um nıvel de granularidade demasiado fino apos a fase de oportunidade. Podera, no

entanto, ser definido um processo de gestao de pedidos de manutencao de acordo com o processo ja

definido.

75

Bibliografia

[1] E.S. Andersen, K. Grude, and T. Haug. Goal Directed Project Management: Effective Techniques

and Strategies. Kogan Page, 2009.

[2] Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK R©

Guide). PMI Standard. Project Management Institute, Incorporated, 2013.

[3] ISACA. COBIT 5: A Business Framework for the Governance and Management of Enterprise IT.

COBIT R© 5. ISACA, 2012.

[4] ISACA. COBIT 5: Enabling Processes. COBIT R© 5. ISACA, 2012.

[5] ISO. Risk management – principles and guidelines. ISO 31000:2009, International Organization

for Standardization, 2009.

[6] ISO. Guidance on project management. ISO 21500:2012, International Organization for Standard-

ization, 2012.

[7] ISO/IEC. Software engineering – software life cycle processes - maintenance. ISO/IEC

14764:2006, International Organization for Standardization and International Electrotechnical Com-

mission, 2006.

[8] ISO/IEC. Systems and software engineering – software life cycle processes. ISO 12207-1:2008, In-

ternational Organization for Standardization and International Electrotechnical Commission, 2008.

[9] ISO/IEC. Systems and software engineering - architecture description. ISO/IEC 42010:2011, In-

ternational Organization for Standardization and International Electrotechnical Commission, 2011.

[10] Great Britain. Cabinet Office. ITIL Continual Service Improvement. Best management practice.

TSO, The Stationery Office, 2011.

[11] Great Britain. Cabinet Office. ITIL Service Design. Best Management Practice. TSO, The Stationery

Office, 2011.

[12] Great Britain. Cabinet Office. ITIL Service Operation. Best Management Practice. TSO, The Sta-

tionery Office, 2011.

[13] Great Britain. Cabinet Office. ITIL Service Strategy. Best management practice. TSO, The Sta-


76

[14] Great Britain. Cabinet Office. ITIL Service Transition. Best management practice. TSO, The Sta-


[15] Great Britain. Cabinet Office. The Official Introduction to the ITIL Service Lifecycle. Best manage-

ment practice. TSO, The Stationery Office, 2011.

[16] Ken Peffers, Tuure Tuunanen, Marcus A Rothenberger, and Samir Chatterjee. A design science

research methodology for information systems research. Journal of management information sys-

tems, 24(3), 2007.

77

Appendix A

Apendices

A.1 Documentos de Suporte da Fase de Oportunidade

Documentos de

SuporteDescricao

Registo da

Oportunidade

- Registo da oportunidade em sistema de tracking da organizacao;

- Identifica a origem, o responsavel pela recepcao e o conjunto de informacao disponibilizada;

- Documento de referencia para o inıcio da analise da oportunidade;

Caso de Negocio - Apresenta a avaliacao, numa perspectiva de negocio, do conjunto de mais-valias da oportunidade;

- Identifica a necessidade de negocio e os custos e benefıcios que justificam e definem as fronteiras do projecto;

Statement of Work- Descricao dos servicos, produtos ou resultados esperados pela oportunidade;

- Identifica, entre outros aspectos: Necessidade de negocio; Descricao do ambito da oportunidade; Plano estrategico

da organizacao (visao, objectivos e metas definidas);

Project

Charter

- Atribui a autoridade ao gestor de projecto para a gestao das actividades de projecto;

- Utilizado para obter a aprovacao necessaria para inıcio do planeamento do projecto;

- Identifica: Razoes da realizacao do projecto; Objectivos mensuraveis e criterios de sucesso relacionados; Lista de

requisitos de alto nıvel; Assumpcoes e constrangimentos; Descricao de alto nıvel do projecto; Identificacao de riscos

de alto nıvel; Sumario das principais milestones do projecto; Sumario de orcamento; Lista de stakeholders; Abordagem a

solucao tecnica;

Maintenance Charter

- Atribui a autoridade ao gestor de manutencao para a gestao de actividades;

- Utilizado para obter aprovacao da manutencao;

- Identifica: Razoes da realizacao da manutencao; Objectivos mensuraveis e criterios de sucesso relacionados;

Lista de requisitos; Calendario da manutencao; Orcamento da manutencao; Recursos necessarios a manutencao; Abordagem a

solucao tecnica;

Portfolio de Projectos/

Manutencoes

- Reune conjunto de oportunidades de projectos e manutencoes geridos em conjunto para alcancar objectivos estrategicos.

- Para cada oportunidade identifica: Responsaveis; Ambito; Calendario; Orcamento; Prioridade;

Tabela A.1: Documentos de suporte ao processo relativos a fase de oportunidade.

78

A.2 Documentos de Suporte da Fase de Planeamento

Documento

de SuporteDescricao

Plano de Gestao

de Projecto

- Tem como objectivo descrever de que forma o projecto sera executado, monitorizado e controlado;

- E composto por um conjunto de baselines definidas durante a fase de planeamento: baseline de orcamento e baseline de calendario;

- Reune ainda um conjunto de planos de gestao individuais: plano de gestao de stakeholders, plano de gestao

de comunicacoes, plano de gestao de riscos, plano de gestao de orcamento, plano de gestao de calendario e plano de gestao de compras;

- Apresenta ainda um conjunto de documentos de auxilio a gestao de projecto, nomeadamente: registo de stakeholders, log de issues,

log de alteracoes, log de riscos e plano de pagamentos.

Registo

de Stakeholders

- Reune todas as informacoes de cada um dos stakeholders do projecto, nomeadamente:

- Identificacao (Nome, cargo na organizacao, papel no projecto, informacao de contacto);

- Avaliacao (Principais requisitos e expectativas para o projecto, impacto no projecto, fase do projecto em que possui maior interesse);

- Classificacao (Interno, externo, neutro - de acordo com a classificacao de stakeholders da organizacao);

- Perfil (Analise de perfil realizada atraves de entrevistas);

Plano de Gestao

de Stakeholders

- Define toda a gestao de stakeholders do projecto, identificando: Nıvel desejavel e actual de compromisso e participacao no projecto

por parte dos stakeholders; Relacoes entre stakeholders; Impacto de alteracoes para os stakeholders; Requisitos de comunicacao por fase

de projecto; Informacao a disponibilizar;

Log de Riscos

- Reune a informacao dos varios riscos identificados no projecto, nomeadamente: Identificacao do risco (causas, consequencias,

impacto e probabilidade); Medidas de tratamento do risco (Lista de medidas de tratamento aplicaveis e as medidas efectivamente aplicadas);

Responsaveis;

Plano de Gestao

de Riscos

- Define toda a gestao de riscos do projecto, identificando: Metodologia para a gestao de risco; Orcamento para a gestao de risco;

Calendarizacao das actividades de gestao de risco; Definicao de probabilidade e impacto de risco; Responsaveis;

Plano de Gestao

de Comunicacoes

- Define toda a gestao de comunicacoes do projecto, identificando: Requisitos de comunicacao; Informacao a comunicar; Canais de

comunicacao e intervenientes; Metodos de comunicacao; Calendario de comunicacao; Responsaveis pela comunicacao;

Procurement

Statement of Work

- Reune conjunto de requisitos do projecto que permitem ao parceiro avaliar se tem capacidade de implementar o projecto;

- Constitui o ponto de partida para o parceiro elaborar uma proposta;

Criterios de

Avaliacao de Propostas

- Conjunto de criterios de avaliacao que permitem avaliar e atribuir uma classificacao concreta a cada proposta recebida;

- Devera ser o mais objectivo possıvel de forma a garantir igualdade no processo de avaliacao;

Plano de Gestao

de Compra

- Documento interno que define aspectos de gestao do procedimento de compra, nomeadamente: Definicao do calendario de compra;

Definicao do orcamento de compra; Identificacao de responsabilidades no processo da compra; Analise de risco da compra;

Proposta de Compra

- Define a proposta do parceiro de acordo com o conjunto de requisitos definidos no procurement statement of work. Identifica: Orcamento

da compra; Calendario da compra; Analise de requisitos; Proposta de solucao; Plano de pagamentos da compra;

- Corresponde ao documento base para a definicao do contracto de compra;

Minuta de

Contracto de Compra

- Documento a assinar pela organizacao e pelo parceiro no momento da formalizacao do contracto;

- Corresponde a aceitacao por parte de ambas as partes (organizacao e parceiro) dos termos da proposta elaborada pelo parceiro.

- Identifica direitos, deveres e obrigacoes de ambas as partes;

Nota de Encomenda - Formalizacao da proposta de compra apresentada pelo parceiro e adjudicada pela organizacao;

- Apresenta o conjunto de entregaveis a fornecer pelo parceiro detalhando-se o prazo de entrega e o plano de pagamentos para cada um deles;

Plano de Gestao

de Custos

- Define o plano de gestao de custos do projecto, identificando: Metodologia de gestao e controlo de orcamento; Informacao a disponibilizar

(conteudo e frequencia); Thresholds de controlo de custos; Descricao dos processos e intervenientes da gestao de custos;

Plano de Gestao

de Calendario

- Define o plano de gestao de calendario do projecto, identificando: Metodos e ferramentas de calendarizacao e controlo do projecto;

Informacao a disponibilizar (conteudo e frequencia); Thresholds de controlo de calendario; Intervenientes da gestao de calendario;

Tabela A.2: Documentos de suporte ao processo relativos a fase de Planeamento.

79

A.3 Documentos de Suporte da Fase de Implementacao e Con-

trolo

Documento de Suporte Descricao

Relatorio de

Progresso Semanal

- Reune um conjunto de informacao do progresso do projecto durante a semana, nomeadamente: Trabalho realizado na semana anterior;

Identificacao e atribuicao de actividades a realizar na semana seguinte; Revisao de orcamento e calendario; Revisao de riscos; Identificacao de

alteracoes; Controlo de alteracoes; Revisao do plano de comunicacoes; Revisao de actividades de gestao de stakeholders; Revisao de issues;

Relatorio de

Progresso Mensal

- Reune um conjunto de informacao do progresso do projecto durante o mes, nomeadamente: Trabalho realizado durante o mes; Planeamento

de calendario do projecto; Forecast de orcamento de projecto; Revisao e analise de riscos prioritarios; Revisao e analise de alteracoes;

Revisao e analise de issues; Revisao do plano de gestao de stakeholders; Analise de eficacia do plano de comunicacoes;

Forecast de Orcamento

- Resulta do progresso do orcamento do projecto do projecto face a baseline de orcamento;

- Apresenta a estimativa de orcamento ate ao fim do projecto com base em previsoes mensais do orcamento;

- Utilizado para controlo de orcamento por parte das areas de projectos, planeamento e controlo e director DSI.

- Permite avaliar discrepancia relativa a baseline de orcamento e cumprimento de tresholds de controlo de orcamento.

Log de Alteracoes - Identifica o conjunto de pedidos de alteracoes, em termos de: Responsaveis; Ambito; Abordagem a solucao tecnica; Orcamento; Calendario;

Recursos; Prioridade;

Log de Issues - Identifica o conjunto de issues do projecto, em termos de: Responsaveis; Causas; Impacto; Prioridade; Medidas de resolucao; Recursos;

Tabela A.3: Descricao dos documentos de suporte ao processo relativos a fase de implementacao econtrolo.

80

A.4 Documentos de Suporte da Fase de Handover

Documentos

de SuporteDescricao

Auto

de Aceitacao

- Reune toda a informacao necessaria para a aceitacao do projecto pela area de projectos,

O&M e negocio, nomeadamente: Entregaveis aceites; Lista de requisitos do projecto; Logs de Alteracoes,

Riscos e Issues; Testes de sistema/aceitacao/outros testes realizados;

Documento

de Handover

- Reune conjunto de documentacao necessaria para o handover da area de projectos a area

de O&M, nomeadamente: Responsaveis pelo Handover ; Log de riscos; Log de issues; Log de alteracoes;

Relatorio de

Fecho de Projecto

- Documento formal que indica o fecho do projecto;

- Reune o fecho de contractos com parceiros;

- Apresenta conjunto de entregaveis aceites do projecto;

- Reune documento de handover e auto de aceitacao do projecto;

- Apresenta o conjunto de logs de risco, issues e alteracoes do projecto;

Licoes Aprendidas

- Resulta do feedback fornecido pela area de negocio, parceiro e todas as areas da direccao de sistemas

de informacao que participaram no projecto, complementado pela experiencia adquirida pelo gestor de projecto.

- Apresenta feedback em aspectos tecnicos do projecto;

- Apresenta feedback em aspectos de gestao do projecto;

- Apresenta feedback em aspectos de qualidade do processo de gestao do projecto;

- Podera ser utilizado pela organizacao para aspectos de melhoria contınua de processos de gestao de projecto;

Tabela A.4: Descricao dos documentos de suporte ao processo relativos a fase de handover.

81

A.5 PMBOK - Processos de Gestao de Projecto

O PMBOK identifica um conjunto de processos para a gestao de projecto, divididos por fases de projecto

e a areas de conhecimento. A divisao dos processos e apresentada na figura A.1, extraıda do PMBOK.

Figura A.1: Processos definidos pelo PMBOK. Extraıdo de [2].

82

Documents

Gestão de Projectos e Gestão da Manutenção nas ... · deﬁnic¸ao e fornecimento de determinado produto, ... 2.1 ISO/IEC 12207: ... 4.9 Actividades detalhadas do processo de