Gestão de Projecto - HomeMarket

Trabalho de Grupo – Gestão de Projectos

1

[ISEG]

Abril 2012

HOMEMARKET – AS COMPRAS MAIS

ECONÓMICAS EM SUA CASA

[Trabalho de Grupo realizado no âmbito da UC V

LIDERANÇA, EMPREENDEDORISMO, E CONCEPÇÃO DE PROJECTOS]

Pós-Graduação em Prospectiva, Estratégia e Inovação

*Francisco Andrade *Marisa Silva *Marta Oliveira


2

ÍNDICE

ÍNDICE ............................................................................................................................................ 1

Introdução ..................................................................................................................................... 3

Metodologia .................................................................................................................................. 4

FASE I – INICIAÇÃO DO PROJECTO ................................................................................................ 6

1. Business Case .................................................................................................................... 7

A. Descrição da Necessidade ............................................................................................. 7

B. Gestão de Requisitos ..................................................................................................... 8

C. Viabilidade Económica ................................................................................................ 10

D. Análise Preliminar do Risco ......................................................................................... 12

E. Identificação e Gestão de Stakeholders ...................................................................... 13

FASE II – ESTRUTURAÇÃO DO PROJECTO .................................................................................... 14

1. Termo de Abertura do Projecto ...................................................................................... 15

2. Plano de Gestão do Projecto ........................................................................................... 18

A. Âmbito ......................................................................................................................... 18

B. Tempo ......................................................................................................................... 23

C. Custo............................................................................................................................ 29

D. Qualidade .................................................................................................................... 31

E. Comunicação ............................................................................................................... 34

F. RH ................................................................................................................................ 38

G. Risco ............................................................................................................................ 47

H. Fornecedores............................................................................................................... 51

I. Gestão de Alterações .................................................................................................. 52

FASE III – REALIZAÇÃO E CONTROLO DO PROJECTO ................................................................... 53

1. Cenários de Execução ...................................................................................................... 54

FASE IV – ENCERRAMENTO DO PROJECTO ................................................................................. 60

1. Termo de Encerramento ................................................................................................. 61

2. Lições Aprendidas ........................................................................................................... 61

Conclusão .................................................................................................................................... 63


3

Introdução

A gestão por projectos, enquanto conjunto de conhecimentos, técnicas e ferramentas que se

traduzem em maior previsibilidade na gestão do orçamento, dos prazos e na satisfação de

clientes, tem vindo a alcançar maior visibilidade no panorama nacional e é cada vez mais

reconhecida como uma resposta eficaz à crescente necessidade de aumento da flexibilidade

orgânica e de aumento das probabilidades de sucesso dos projectos levados a cabo pelas

organizações.

Reconhecendo a importância desta ciência e arte, e no âmbito da unidade curricular de

Concepção de Projectos, procura-se no trabalho seguidamente exposto aplicar os conceitos

adquiridos na metodologia, considerando um projecto em todas as suas fases, desde a sua

justificação através de uma análise de viabilidade, estruturação, execução e controlo e

término.

Ressalve-se que, dado tratar-se este de um trabalho académico, de aplicação de

conhecimentos, optou-se por abordar as áreas de conhecimento de uma forma não exaustiva

mas antes fundamental.

Ainda que se trate de um trabalho teorético, de simulação, o Grupo está certo que o mesmo

servirá de preparação para projectos vindouros, onde poderá então aplicar devidamente as

lições aprendidas que daqui advirão.


4

Metodologia

A metodologia de Gestão de Projecto a aplicar no projecto HomeMarket visa impulsionar a

excelência da sua gestão e proporcionar à Equipa de projecto, os processos, os modelos e as

ferramentas mais adequadas para aumentar a probabilidade de sucesso do mesmo.

Assim, procurar-se-á seguir as melhores recomendações internacionais de Gestão de Projecto

preconizadas pelo PMI e IPMA, e alinhadas com a ISO 21500 e com o devido tailoring às

especificidades do projecto.

A evolução do projecto de acordo com a metodologia adoptada pela MMF pode ser

sumarizada através do seguinte ciclo de vida da gestão do projecto:

• Iniciação – Apresentação de uma necessidade/oportunidade de negócio e elaboração

de uma análise inicial de risco, viabilidade e análise estratégica, para suportar uma

decisão de go/no go, consubstanciada num Business Case.

• Planeamento – Após a decisão de avançar, é elaborado o Plano de Gestão do Projecto,

constituído por uma colecção de planos subsidiários detalhados (plano detalhado de

actividades, respectivas sequências e dependências, lista de milestones e calendário

de execução, plano de comunicação, plano de riscos, plano de recursos, gestão de

alterações, etc.) que é a fonte primária de informação sobre como o projecto será

executado, monitorizado, controlado e gerido.

• Execução – O plano de projecto aprovado determina a execução do projecto, havendo

lugar a revisão ao plano inicial e maior detalhe necessário (rolling wave). São

realizadas as actividades e processos definidos no plano do projecto, e tem lugar a

coordenação de pessoas e recursos, a execução do trabalho, o cumprimento de

milestones e as entregas do projecto.

• Controlo – Actividades paralelas à Execução, em que é realizada monitorização e

controlo do progresso do projecto, através da identificação permanente de riscos,

controlo de alterações, reporting com recursos à técnica EVM, entre outros.

• Encerramento – Grupo de actividades relacionadas com o fecho do projecto/fase. É

neste grupo de actividades que se obtém a aceitação formal para o projecto global, é

elaborado o relatório de avaliação do projecto e são fechados os contractos com

fornecedores, se aplicável. Os produtos/serviços passam à fase de exploração e são


5

igualmente documentadas as Lições Aprendidas e arquivados os documentos do

projecto como histórico e referência para futuros projectos.

Apesar de estas fases se encontrarem descritas de uma forma aparentemente sequencial, as

actividades e processos que as constituem sofrem várias iterações dentro do mesmo grupo ou

entre grupos, e sobrepõem-se ao longo o ciclo de vida do projecto.

Por exemplo, as actividades de planeamento são revistas, detalhadas ou alteradas à medida

que o projecto evolui (proporcionando mais detalhe) e que surgem alterações, novos riscos e

incidentes.

O gestor de projecto utiliza as fases de modo a:

• Assegurar que os work packages são executados de uma forma lógica;

• Dividir o projecto no tempo em elementos que possam ser mais eficientemente

geridos;

• Minimizar os riscos;

• Estabelecer pontos nos quais os planos e estimativas possam ser revistas e redefinidas

com base no trabalho executado;

• Permitir que a gestão aprove ou que o projecto seja reformulado de acordo com o

trabalho realizado.


6

FASE I – INICIAÇÃO DO PROJECTO


7

1. Business Case

Não deve esquecer-se que um projecto não é um fim em si mesmo mas antes um meio para

atingir um dado fim, isto é, deverá ter uma justificação ao nível do negócio no que respeita a

benefícios associados, sejam de rentabilidade, poupança, conformidade ou outros, e

alinhamento com a estratégia da organização.

Note-se que a qualquer projecto está associada uma vertente de investimento, pelo que o

Business Case assume-se de especial relevância pois representa o conjunto de informação

necessária para julgar se o projecto é desejável, viável e alcançável e, portanto, se vale o

investimento a realizar.

A. Descrição da Necessidade

A actual situação económico-financeira vivida em Portugal, tem levado cada vez mais famílias

portuguesas a ter especial atenção na hora de gastar o seu dinheiro. Como todos sabemos as

despesas de supermercado representam uma fatia considerável do orçamento familiar.

Foi desta necessidade de poupar que surgiu o projecto Home Market, uma ideia da empresa

de consultoria MMF Consulting em parceira com a Deco Proteste. A principal motivação no

desenvolvimento desta solução é ajudar os consumidores a conseguir o melhor preço final

para as suas compras de supermercado.

O projecto prevê a criação de uma plataforma online de comparação de preços de diversos

supermercados nacionais com presença online.


8

B. Gestão de Requisitos

As funcionalidades/ requisitos a ser implementadas serão:

• Integração com os sistemas online (base dados ou serviços) dos supermercados

Continente, Jumbo e Pingo Doce.

• Comparador de preços online – Será possível ao cliente criar a sua lista de compras,

sendo possível definir diversos parâmetros para obter o preço mais barato na rede de

supermercados associados.

• Aconselhamento de produtos – O Cliente será aconselhado para outros produtos

idênticos mais económicos.

• O Cliente pode registar-se no serviço online

• O Cliente poderá guardar a sua lista e continuar posteriormente.

• O Cliente poderá comprar todos os produtos da sua lista, que será entregue em casa

posteriormente, este serviço terá um custo associado.

• Através de uma aplicação móvel o cliente poderá adicionar mais produtos à sua lista

de compras.

• O portal deverá ter zonas reservadas para publicidade, que serão geridas

automaticamente.

• Gestão de Clientes – CRUD de utilizadores por parte da administração.

• Gestão de produtos – CRUD de produtos por parte da administração.

• Gestão de encomendas – CRUD de encomendas por parte da administração.

• Gestão de publicidade – CRUD de publicidade por parte da administração.

• O portal deverá correr nos principais browsers do mercado:

o Chrome

o Firefox

o IE8

o Safari

o Opera

• Aplicação móvel será implementada para os sistemas:

o Android (Google)

o IOS (Apple)

o Windows Phone (Microsoft)


9

O Sistema deverá receber o input de preços de vários supermercados online, essa

comunicação deverá ser feita através de serviços disponibilizados pelos próprios

supermercados.

A plataforma principal deverá ser instalada numa VPS de modo a garantir uma boa

performance. A tecnologia para desenvolvimento será JAVA com o servidor aplicacional JBoss

Aplication Server.

As aplicações para mobile serão desenvolvidas utilizando as APIs originais de cada SO

específico.

Home

Market

Continente Online

Pingo Doce Online

Jumbo

Online


10

Ciclo de Vida do Produto 5 anos

Inflação 1,75% ano

Financeiros 223.230,00 €

MIN MP MAX

Publicidade vendida + Nº de visualizações de página 3.000.000 4.800.000 5.500.000 0,015 € Valor médio publicidade vendida por ano 69.250,00 €

Margem sobre as compras + N.º de entregas realizadas 12.000 24.000 36.000 5 € Valor médio de uma entrega por ano 120.000,00 €

Subscrições + N.º de subscritores 1.000 2.000 3.000 16,99 € Valor médio de uma subscrição por ano 33.980,00 €

Benefício +/-Frequência/Ano

Métrica MédiaUnidade Frequência (Número, %) Descrição da métrica

C. Viabilidade Económica

A análise de viabilidade do projeto permite, comparando, entre outros, custos e benefícios,

aferir se o projeto vale ou não o investimento e se representa verdadeiramente benefício para

a empresa.

Como orçamento para o projeto foi aprovado o valor de 100.000€. Este foi desenvolvido por

estimativa análoga e tendo por base a análise de custos dos recursos necessários,

equipamentos e serviços associados.

Para a medição dos benefícios financeiros resultantes da exploração do projeto, consideraram-

se três grandes fontes de receita:

• Publicidade “vendida” no website – mensurável através do número de visualizações de

página, em que cada visualização constituiu um retorno de 0,015€;

• Margem sobre as compras – às entregas de compras realizadas assistirá uma margem

diferenciada de acordo com o valor global da compra, para a qual se estimou um valor

médio de 5€;

• Subscrições – para que os utilizadores disponham de funcionalidades avançadas, como

guardar histórico, imprimir lista de compras ou utilizar gratuitamente as aplicações

mobile, ser-lhes-á exigida a modalidade de uma subscrição, mensal ou anual, de

acordo com as suas preferências; para esta definiu-se o valor anual de 16,99€.

De acordo com estas métricas anuais e com base em projectos anteriores e dados de

referência do sector publicados que permitiram aferir um intervalo de ocorrências, concluiu-se

então um benefício anual de 223.230,00€.


11

10% ano

Ano Investimento Benefícios Factor Act Inv Act Ben Act Cash Flow Nom Cash Flow Cum Nom Cash Flow Cum Act

0 100.000 € 1,00 € 100.000 € - € 100.000 €- 100.000 €- 100.000 €-

1 223.230 € 0,91 € - € 202.936 € 223.230 € 123.230 € 102.936 €

2 223.230 € 0,83 € - € 184.488 € 223.230 € 346.460 € 287.424 €

3 223.230 € 0,75 € - € 167.716 € 223.230 € 569.690 € 455.140 €

4 223.230 € 0,68 € - € 152.469 € 223.230 € 792.920 € 607.609 €

5 223.230 € 0,62 € - € 138.608 € 223.230 € 1.016.150 € 746.217 €

100.000 € 1.116.150 € Ref Ano 0 100.000 € 846.217 €

Fase: Projecto Exploração

Lucro = ? 1.016.150 € VAL (Valor Actual Liquido) = 746.217 €

BCR (Benefit Cost Ratio) = 8,46 €

TIR (Taxa Interna de Rentabilidade) = 222,6%

Payback = 5,4 meses

Tx Interesse =

Embora, numa primeira abordagem, este pareça ser um bom resultado, deverá ser comparado

com os custos previstos para o projecto considerando a actualização daqueles valores ao longo

do tempo.

Assim, da análise de Modelo Económico, considerando uma taxa de interesse de 10%/ano e

um ciclo de vida de 5 anos, obtiveram-se os seguintes:

Esta análise permite concluir da viabilidade económica do projeto, já que se traduz num VAL

positivo de 746.217€, representando um rácio custo/benefício de 8,46€, isto é, por cada 1 Euro

investido, 8,46€ são benefício. Analisando ao nível da TIR, esta apresenta também um valor

positivo e superior à taxa de interesse definida, pelo que o projeto tem também a este nível

parecer positivo.

Atendendo ao payback, verifica-se ainda que o projeto “paga-se” ao 5,4 meses, o que é um

indicador importante para avançar para o Go do projecto.

Note-se porém que esta análise confronta investimento (fase de projecto) e seus benefícios,

excluindo os normais custos fixos e de manutenção que decorrem da fase de exploração.

Contudo, para estes, não é expectável, de acordo com projectos semelhantes realizados

anteriormente, que ultrapassem o benefício ali espelhado.


12

D. Análise Preliminar do Risco

Os riscos fazem parte de qualquer projecto, variando na sua importância e impacto, tendo em

conta o tipo de projecto em causa.

Numa análise de viabilidade do projecto, este vector tem especial importância podendo

determinar a decisão de avançar ou não.

Por estarmos ainda numa fase muito preliminar do projecto, designada até de pré-projecto,

não dispomos ainda de muita informação. Porém, atendendo à disponível e ao histórico da

empresa neste tipo de projectos, podemos enumerar os seguintes riscos:

Estes riscos serão mais amplamente explorados e monitorizados durante a execução do

projecto, no plano de gestão do Risco.

RISCO

Falha no orçamento de implementação Falta de apoio e envolvimento da alta direcção Perda de prioridade do projecto na organização Envolvimento insuficiente dos utilizadores na implementação do sistema Falta de integração e/ou confiança entre o implementador e o cliente Mudanças nos requisitos do sistema durante a fase de projecto Falha na estimativa dos prazos de implementação Dificuldades de integração com outros serviços externos Arquitectura inadequada da implementação Testes do sistema pouco efectivos

13

E. Identificação e Gestão de Stakeholders

Uma primeira identificação dos Stakeholders envolvidos no projecto é essencial para

complementar a sua análise de viabilidade. Para o projecto HomeMarket, foram

primeiramente identificados os seguintes:

Consideram-se Stakeholders internos, os actores-base do projecto, que estão intrinsecamente

ligados ao mesmo. Neste caso o Sponsor, a Deco Proteste, também definido como parceiro

estratégico, tem a notoriedade, conhecimento e experiência em elaborar estudos e análises

técnicas e económicas a variados produtos do mercado, com interesse para o consumidor,

considerados necessários para este projecto.

Por outro, a MMF Consulting é a consultora responsável pelo projecto, responsável pela

gestão do mesmo.

Consideram-se ainda os seguintes, externos:

• Super/hipermercados: Continente, Pingo Doce e Jumbo

• Consultores e programadores informáticos (Equipa)

• Departamento legal – Advogados

• Developers Mobile (fornecedor)

Estes serão mais amplamente analisados posteriormente, no capítulo da Comunicação.


14

FASE II – ESTRUTURAÇÃO DO PROJECTO


15

1. Termo de Abertura do Projecto

1. IDENTIFICAÇÃO <Identifica o projecto.>

Código do Projeto P_06_2012

Nome do Projeto HomeMarket Gestor do Projeto Baltasar Sete-Sóis, IPMA-C, PMP

Sponsor do Projecto Eng. AA (MMF Consulting)

Cliente do Projecto Dr. BB (Deco Proteste)

3. ÂMBITO DO PROJECTO <Identifica os principais entregáveis do projecto bem como datas de

entrega estimadas.>

No Âmbito Target Date

Caderno de Especificações 06-08-2012

Documento de Arquitectura 14-08-2012

Documento de User Interface 13-08-2012

Ficheiros PSD 15-08-2012

Ficheiros HTML 17-08-2012

Configuração Ambiente Desenvolvimento 20-08-2012

Configuração Ambiente Testes 21-08-2012

Configuração Ambiente Produção 22-08-2012

Scripts de Base de Dados 28-08-2012

Deploy para Ambiente Testes 15-10-2012

Caderno Testes 18-10-2012

Testes 02-11-2012

Manual Utilizador 12-10-2012

Manual Administração 17-10-2012

Entrada em Produção 05-11-2012

2. JUSTIFICAÇÃO <Descreve objectivos, oportunidade ou problema que o projecto vem

resolver, ie, a justificação do projecto.>

A actual situação económico-financeira vivida em Portugal, tem levado cada vez mais famílias portuguesas a ter especial atenção na hora de gastar o seu dinheiro. Como todos sabemos as despesas de supermercado representam uma fatia considerável do orçamento familiar.

Foi desta necessidade de poupar que surgiu o projecto HomeMarket, uma ideia da empresa de consultoria MMF Consulting em parceria com a Deco Proteste, em que se pretende ajudar os consumidores a conseguir o melhor preço final para as suas compras de supermercado através da criação de uma plataforma online de comparação de preços de diversos supermercados nacionais com presença online.


16

5. MILESTONES <Identifica os principais milestones do projecto>

Milestone Data Estimada

Início do projecto 06-07-2012 Go live 05-11-2012

Fim do projecto 13-11-2012

6. CONSTRANGIMENTOS <Descreve restrições do projecto no que respeita ao cronograma,

orçamento, recursos, entre outros condicionantes ao projecto>

Tipo de Constrangimento Descrição

Cronograma O site tem que estar disponível antes de 15 de Março, dia Mundial dos Direitos do Consumidor

Orçamento O orçamento disponibilizado está limitado a 100.000€

7. PRESSUPOSTOS <Descreve pressupostos do projecto, que deverão ser validados.>

Tipo de Pressuposto Descrição

Acesso a Dados Externos Disponibilidade das cadeias de hipermercados para permitir o acesso em tempo real e directamente aos preços de venda

Disponibilidade da Equipa Disponibilidade da Equipa de acordo com as alocações planeadas

Fornecedores Domínio na implementação de soluções mobile

Disponibilidade do Cliente Disponibilidade do Cliente para validações e aceitação de entregáveis

4. NÃO-ÂMBITO DO PROJECTO <Identifica aquilo que não constitui entregável do projecto.>

Tudo o que não está explicitamente incluído na tabela acima está implicitamente excluído: Formação aos administradores Contractos com estafetas Outros


17

9. FACTORES CRÍTICOS DE SUCESSO <Identifica quais os factores críticos que terão de se

verificar para conduzir ao sucesso do projecto.>

ID Factor

1 Definição clara do âmbito do projecto, nomeadamente, requisitos dos entregáveis

2 Sponsorship e envolvimento do Cliente

3 Comunicação constante entre a Equipa e Gestor de Projecto

4 Disponibilidade do Cliente para esclarecimento de dúvidas e validações

5 Processo de controlo de alterações bem definido e conhecido por todos

10. APROVAÇÃO <A aprovação do Termo de Abertura indica que o conteúdo deste documento

foi compreendido e aceite. Quando assinado, o projecto descrito é formalmente reconhecido

e é atribuído ao Gestor de Projecto o poder para iniciar o projecto.>

O Sponsor do Projecto:

__________________________________

Eng. AA, MMF Consulting

Lisboa, 06 de Julho de 2012.

8. MODELO DE GOVERNO <Identifica momentos de controlo no projecto.>

Modelo de Governo Informação

Ponto de Situação com Equipa

Periodicidade Semanal

Dia / Hora Sextas-feiras / 12h-13h

Reunião de Steering Periodicidade Mensal

Dia / Hora Última Quinta-feira / 16h-18h


18

2. Plano de Gestão do Projecto

O plano de Gestão do Projecto é um documento essencial para o projecto, contendo nos seus

vários planos subsidiários orientações importantes sobre como o projecto será executado,

gerido e controlado. Este é um documento que deve ser revisto e alimentado ao longo do

tempo, de acordo com a evolução do projecto.

A. Âmbito

O âmbito do projecto é a manifestação daquilo que é o projecto, ao nível das entregas que

deverão ocorrer e tem a sua representação e instanciação na WBS.

A Work Breakdown Structure (WBS) representa a estrutura de decomposição do trabalho, isto

é, traduz aquilo que o trabalho vai entregar, sob uma forma hierárquica e orientada ao

entregável. O seu objectivo é decompor o trabalho em elementos cada vez menores, até ao

menor nível gerível, o do work package.

Em conjunto com o Dicionário da WBS e com a definição do âmbito (scope statement),

representam a baseline do âmbito do projecto.

Para o projecto Home Market definiu-se a seguinte WBS, composta por cinco fases, e

representada de forma gráfica abaixo, com os diferentes work packages:

0. Projecto Home Market

1. Iniciação

1.1. Business Case

1.2. Termo de Abertura

2. Estruturação

2.1. Plano de Projecto

2.2. Plano de Gestão de Projecto

2.3. Reunião de Kick-off


19

3. Execução

3.1. Análise

3.1.1. Especificações

3.1.1.1. Caderno de Especificações

3.2. Design

3.2.1. Arquitectura

3.2.1.1. Documento de Arquitectura

3.2.2. User Interface

3.2.2.1. Documento de User Interface

3.2.3. Design

3.2.3.1. Ficheiro PSD

3.2.3.2. Ficheiros HTML

3.3. Implementação

3.3.1. Configuração

3.3.1.1. Configuração do Ambiente de Desenvolvimento

3.3.1.2. Configuração do Ambiente de Testes

3.3.1.3. Configuração do Ambiente de Produção

3.3.2. Integração

3.3.3. Base de Dados

3.3.3.1. Scripts de Base de Dados

3.3.4. Core

3.3.5. Interface

3.3.5.1. Deploy para ambiente de Testes

3.4. Verificação

3.4.1. Caderno de Testes

3.4.2. Testes

3.5. Documentação

3.5.1. Manual de Utilizador

3.5.2. Manual de Administração

3.6. Rollout

3.6.1. Entrada em Produção

4. Monitorização e Controlo

5. Encerramento

5.1. Termo de Encerramento

5.2. Lições Aprendidas

20

0. Projecto Home Market

1. Iniciação

1.1 Business Case

1.2 Termo de Abertura

2. Estruturação

2.1 Plano Projecto

2.2 Plano GP

2.3 Reunião kikc-off

3. Execução

3.1 Análise

3.1.1 Especificações

3.2 Design

3.2.1 Arquitectura

3.2.2 User Interface

3.2.3 Design

3.3 Implementação

3.3.1 Configuração

3.3.2 Integração

3.3.3 Base de Dados

3.3.4 Core

3.3.5 Interface

3.4 Verificação

3.4.1 Caderno Testes

3.4.2 Testes

3.5 Documentação

3.5.1 Manual Utilizador

3.5.2 Manual Administração

3.6 Rollout

3.6.1 Entrada Produção

4 Monitorização e Controlo

5 Encerramento

5.1 Termo Encerramento

5.2 Lições Aprendidas

WBS do Projecto

21

Dicionário da WBS

O Dicionário da WBS constitui-se de especial relevância, já que dota a Equipa de uma

linguagem comum e permite que todos tenham um entendimento claro sobre a natureza de

cada elemento da WBS.

ID Elemento da WBS Descrição Critério de Aceitação

1 Iniciação

1.1 Business Case Documento que justifica a realização do projecto, viabilidade e sua exequibilidade

Conforme template da empresa; validado pelo PMO e disponível e aceite pelo Cliente

1.2 Termo de Abertura Documento que formaliza a existência do projecto e autoriza o Gestor de Projecto a iniciar o projecto

Conforme template da empresa; validado pelo PMO; assinado pelo Sponsor

2 Estruturação

2.1 Plano de Projecto

Plano que apresenta a estrutura de actividades, sequenciação, recursos, etc, e que é utilizado para planeamento e controlo do projecto

Conforme template MS Project da empresa; validado pelo PMO; disponível e aceite pelo Cliente

2.2 Plano de Gestão de Projecto

Conjunto de documentos que define como o projecto será planeado, gerido e controlado nas suas diferentes componentes (âmbito, tempo, custo, qualidade, comunicação, etc)

Conforme template da empresa; validado pelo PMO; disponível e aceite pelo Cliente

3 Execução 3.1 Análise

3.1.1 Caderno de Especificações O caderno de especificações detalhe requisitos técnicos e de negócio da solução

Conforme requisitos levantados; disponível e aceite pelo Cliente

3.2 Design 3.2.1 Arquitetura

3.2.1.1 Documento de Arquitetura Este documento especifica a arquitetura da solução a implementar.

Incluir especificações técnicas e diagramas de fluxos de dados; disponível e aceite pelo Cliente

3.2.2 User Interface

3.2.2.1 Documento User Interface O documento de User Interface define a disposição da interface de utilizador

Incluir wireframes finais validados pelo cliente, assim como o relatório de testes de usabilidade realizados; disponível e aceite pelo Cliente

3.2.3 Design

3.2.3.1 Ficheiros PSD Ficheiro vectorial produzido pelo designer

Conforme Documento de User Interface; ficheiros disponíveis e template aceite pelo Cliente

3.2.3.2 Ficheiros HTML Ficheiros HTML produzidos com base nos ficheiros PSD

Conforme ficheiros PSD; Ficheiros HTML disponíveis e


22

validados pela W3C

3.3 Implementação

3.3.1 Configuração Nesta fase deverão ser configurados os vários ambientes de desenvolvimento

Conforme Documento de Arquitectura; Ambientes disponíveis e configurados

3.3.2 Integração

Inícios da codificação da solução, os serviços de integração serão desenvolvidos nesta fase. São estes serviços que permitirão ao HomeMarket comunicar com entidades externas (supermercados)

API’s disponíveis

3.3.3 Base de Dados

Definição do modelo de dados a utilizar de acordo com os requisitos e arquitetura. Serão entregues os scripts para criação da base de dados

Script de base de dados disponível e aceite pelo Cliente

3.3.4 Core Implementação das principais funcionalidades do negócio

Ficheiros de código fonte aceites pela Qualidade

3.3.5 Interface

Implementação dos ecrãs da aplicação que vão comunicar diretamente com as funcionalidades de negócio implementadas no core

Plano de interfaces disponível e aprovado pelo Cliente

3.4 Verificação

3.4.1 Caderno de Testes Construção dos casos de testes, mapeados aos requisitos identificados

Lista da associação entre os requisitos e os casos de teste

3.4.2 Testes Realização de testes, de acordo com caderno de testes

Conformidade com caderno de testes e relatórios da execução dos testes

3.5 Documentação

3.5.1 Manual do Utilizador Documento produzido para auxiliar o utilizador durante a utilização do Homemarket

Conforme template disponível na empresa; disponível e aprovado pelo Cliente

3.5.2 Manual de Administração Documento produzido para ser utilizado pelos administradores do site (backoffice)

Conforme template disponível na empresa; disponível e aprovado pelo Cliente

3.6 Rollout Fase final em que o HomeMarket é disponibilizado aos primeiros utilizadores

Plano de rollout entregue e aceite pelo cliente; relatório de ocorrências

4 Monitorização e Controlo

4.1 Actividades de GP Inclui reuniões, steering, reporting, etc

Conforme templates e metodologia disponível na empresa; validado pelo PMO

5 Encerramento

5.1 Termo de Encerramento Documento que formaliza o fecho do projecto

Inclui tabela de variâncias; conforme template disponível na empresa; validado pelo PMO; disponível e aceite pelo Cliente

5.2 Lições Aprendidas Documento que registas as lições aprendidas com o projecto

Conforme template disponível na empresa; validado pelo PMO; inclui contributos de toda a Equipa


23

B. Tempo

A componente de Schedule constitui um dos elementos cruciais na triple constraint.

Para a estimativa de duração e esforço das actividades do projecto utilizou-se a abordagem

PERT, de três pontos, isto é, solicitou-se a cada elemento da Equipa envolvido na actividade

que apontasse uma estimativa pessimista, optimista e a mais provável para a sua execução.

Da mesma forma, também para a definição de dependências entre actividades se consultou a

Equipa, tendo-se daí obtido a seguinte timeline que espelha de uma forma rápida e objectiva

os principais milestones do projecto:

O cronograma final abaixo apresentado (após nivelamento de recursos e optimização do plano

de projecto), sob a forma de Gantt Chart, mostra com maior detalhe a sequenciação e duração

das actividades, num total de 107 dias de duração de projecto.

24


25


26

27

A sumarização dos principais eventos do projecto, pode ainda definir-se pelo Milestone Chart

abaixo:

Milestones Data Estimada

Business case aceite 05-07-2012 Fim de Iniciação 06-07-2012 Fim de planeamento 25-07-2012 Caderno de especificações aceite 06-08-2012 Documento de arquitectura aceite 14-08-2012 Documento de usabilidade aceite 13-08-2012 Template aceite 15-08-2012 Ficheiros HTML validados pela W3C 17-08-2012 Design concluído 17-08-2012 Configuração de Ambientes concluída 22-08-2012 Ficheiros de código fonte aceites pela Qualidade 28-09-2012 Deploy concluído com sucesso 15-10-2012 Testes concluídos com sucesso 02-11-2012 Go live 05-11-2012 Fim de Execução 05-11-2012 Fim do Projecto 13-11-2012

De acordo com a rede de precedências definidas, resultou o seguinte caminho crítico, visível

esquematicamente no Network Diagram representado, bem como, com mais detalhe, na

indicação de quais as actividades que são críticas, isto é, aquelas com folga de zero dias e,

portanto, onde não se pode verificar qualquer atraso sob prejuízo de impactar na data fim do

projecto:


28


29

C. Custo

A componente de custo é, a par da de Schedule, uma das mais prementes na gestão do

projecto.

Para o projecto HomeMarket foi disponibilizado um budget de 100.000€.

Considerando que uma elevada proporção dos custos advém da utilização dos recursos

humanos (work), apresenta-se seguidamente as standard rates horárias que foram

consideradas, de acordo com a prática do mercado:

Recurso Rate

Analista de Negócio 50 € Gestor de Projecto 60 € System Architect 60 € Web Designer 40 € User Interface Designer 40 € System Administrator 60 € Developer Jr. 25 € Developer Sr. 40 € Tester 25 € Technical Writer 30 € PMO Manager 40 €

No que respeita à decomposição dos custos planeados, estes distribuem-se da seguinte forma:

Orçamento Total 100.000€

Reserva de Gestão 3.505€ Baseline Cost 96.495€

Reserva de Contingência 2.000€ Custos com Recursos Humanos 82.495€

Analista de Negócio 6.550€ Gestor de Projecto 41.880€ System Architect 6.600€ Web Designer 1.840€ User Interface Designer 2.000€ System Administrator 2.940€ Developer Jr. 5.300€ Developer Sr. 9.480€ Tester 2.775€ Technical Writer 1.590€ PMO Manager 1.540€

Custos com Fornecedores 12.000€ Contrato de Consultoria 12.000€


30

Assim, a baseline de custo do projecto é de 96.495€. Este valor inclui uma reserva de

contingência, conforme melhores práticas de Gestão de Projecto, a fim de fazer face a

eventuais riscos conhecidos que possam verificar-se no projecto. O valor remanescente face

ao budget disponibilizado será considerado na rubrica de reserva de gestão para fazer face a

riscos desconhecidos que possam ocorrer.


31

Qualidade

Plan

Do

Check

Act

D. Qualidade

A Gestão da Qualidade tem como objectivo a implementação de políticas e procedimentos que

garantam, tanto quanto possível, que o projecto atinge os objectivos e satisfaz as necessidades

para que foi concebido.

Os principais processos definidos são:

• Planear a qualidade – Identificar os standards, políticas ou procedimentos de

qualidade, disponíveis para o tipo de projecto em causa e para a qualidade do esforço

de gestão de projecto.

• Executar a Garantia da Qualidade (Quality Assurance) – Conjunto de actividades que

asseguram que os procedimentos da qualidade estão a ser devidamente realizados.

Engloba auditorias periódicas ao projecto durante a sua execução.

• Controlar a Qualidade (Quality Control) – Conjunto de actividades que têm como

objectivo, garantir o nível de qualidade definido e planeado, “medindo” o grau de

conformidade com o definido no Plano de Qualidade.

Os processos de qualidade definidos para o projecto estão alinhados com o Sistema de Gestão

da Qualidade da MFF e serão objecto de melhoria contínua, num processo típico de PDCA

(Plan-Do-Check-Act), ilustrado na figura abaixo:


32

• Planear (Plan) – Os processos são objecto de planeamento;

• Fazer (Do) – Os processos são executados;

• Rever (Check) – Os processos são auditados para verificar a sua adequação e são

planeadas melhorias sempre que tal seja necessário;

• Agir (Act) – As melhorias são implementadas nos processos

Atendendo ao âmbito do projecto, um dos standards que a Equipa procurará seguir respeita à

ISO 9126 que aborda as métricas de qualidade de software, nos critérios abaixo

representados:

Para o projecto, além da exigível conformidade aos requisitos, e integrando os melhores

princípios do SEI-CMMI, a qualidade do software será mensurável através dos seguintes

parâmetros:


33

Medida Métrica

Funcionalidade Coerência entre os requisitos levantados inicialmente e as funcionalidades efectivamente entregue.

Confiabilidade Rácio entre número de linhas de código e erros detectados. Rácio entre erros levantados e corrigidos na fase de testes.

Usabilidade Coerência entre os ecrãs definidos na fase de design e os ecrãs que foram efectivamente implementados.

Eficiência Análise da performance na solução. Eficiência na resolução do problema apresentado inicialmente.

Manutenibilidade Rácio entre número de linhas de código e funcionalidades. Analisar a complexidade do código produzido, utilizando ferramentas para métricas.

Portabilidade Analisar a portabilidade da solução entre os vários browsers e sistemas operativos.

Todos os processos que formam o projecto consideram ainda as recomendações do normativo

ISO 9001:2008, uma vez que a MMF tem em curso a preparação da certificação do seu Sistema

de Gestão da Qualidade.

Porque o projecto assenta sobre uma Gestão de Projecto profissional, tem-se ainda em

consideração as boas recomendações da actual ISO 10006:2003, e os correntes

desenvolvimentos da futura ISO 21500, tendo-se desenvolvido ainda, ao nível da ferramenta

de planeamento e controlo MS Project, uma vista para o controlo da Qualidade do

planeamento, por parte da Gestão do Projecto.


34

E. Comunicação

Qualquer projecto, para ser bem-sucedido, tem inerente a necessidade de uma comunicação

eficaz, correta e oportuna entre todas as partes interessadas, os Stakeholders, que sofrerão o

impacto do projecto e/ou exercerão influência sobre o mesmo, com os seus diferentes níveis

de interesse e poder.

Obter o buy-in e engajamento de todos os Stakeholders, em especial dos considerados chave

para o projecto, é, de resto, um factor crítico de sucesso que deve ser perseguido.

Efectivamente, uma efectiva gestão de Stakeholders implica a maximização dos apoios e a

minimização das ameaças, através do necessário envolvimento e tendo em conta a velha

máxima de que “ninguém destrói aquilo que ajuda a construir”.

Os Stakeholders-chave assumem assim papéis críticos na comunicação do valor do projecto e,

por conseguinte, exigem por parte da gestão do projecto um acompanhamento constante.

Para obter o nível de compromisso pretendido para cada um dos grupos-chave é necessária

uma abordagem sistemática na gestão da comunicação relacional com cada um destes grupos,

ao longo do ciclo de vida do projecto.

O processo de comunicação a seguir no projecto atenderá aos seguintes eixos de actuação.

• Identificar os Stakeholders

• Avaliar e classificar os Stakeholders-chave do projecto

• Estabelecer uma estratégia e plano de gestão dos Stakeholders, de forma a se

estabelecer e definir acções concretas de gestão de cada stakeholder mediante o seu

interesse e poder e comportamento pretendido face ao projecto

• Analisar de forma regular os Stakeholders-chave ao longo do projecto, com

mapeamento das respectivas posições e acompanhamento de tendências.

Identificação e Gestão de Stakeholders

Existindo vários actores, internos e externos, aptos a influenciar um projecto, o Gestor de

Projecto deve procurar identificar o mais cedo possível os Stakeholders impactados e com

impacto no projecto.


35

Nesse sentido, para o projecto HomeMarket, foram identificados os Stakeholders abaixo:

Nome Organização Papel Poder Interesse Estratégia

Eng. AA MMF Sponsor Elevado Poder

Elevado Interesse

Gerir Activamente

Dr. BB Deco

Proteste Cliente

Elevado Poder

Elevado Interesse

Gerir Activamente

CC Continente Participante Moderado

Poder Moderado Interesse

Manter Satisfeito

DD Pingo Doce Participante Moderado


Manter Satisfeito

EE Jumbo Participante Moderado


Manter Satisfeito

FF Mais Mobile Develop. Sr. Fornecedor

Reduzido Poder

Moderado Interesse

Manter Informado

FI Mais Mobile Develop. Jr. Fornecedor

Reduzido Poder

Reduzido Interesse

Monitorizar

ADV Deco

Proteste Dep. Legal

Elevado Poder

Reduzido Interesse

Manter Satisfeito

Note-se que a identificação de Stakeholders é um processo vivo e contínuo, já que no decorrer

do projecto novos Stakeholders podem surgir ou pode haver lugar a alterações nos factores

(ex. poder, interesse) inicialmente enumerados.

De acordo com a informação registada acima, no que concerne à classificação dos

Stakeholders, é possível agora traçar a matriz de gestão de Stakeholders assim esquematizada:

Gerir

Activamente

Manter

Satisfeito

Manter

Informado Monitorizar

Poder

Interesse

AABB

CC

DD

EE

FF

FI

ADV


36

Para concretizar a estratégia de gestão de Stakeholders são considerados os seguintes planos

de acção:

Nome Comportamento Plano de Acção

Eng. AA Apoiante Envolvimento integral no projecto

Dr. BB Apoiante Reuniões mensais, comunicação constante, almoços

semanais

CC Neutro

Desenvolver relação de confiança com a cadeia de supermercado, mantendo informado da evolução do

projecto, convidar para acção de team building do projecto com storytelling de apresentação benefícios

DD Bloqueante


projecto, convidar para acção de team building do projecto com storytelling de apresentação benefícios,

marcar almoço

EE Apoiante


projecto, convidar para acção de team building do projecto com storytelling de apresentação benefícios

FF Neutro Envolver com Equipa interna, convidar para acções de

comemoração milestones

FI Apoiante Envolver com Equipa interna, convidar para acções de

comemoração milestones

ADV Apoiante Manter a boa relação entre as marcas/supermercados presentes no sistema, Reuniões mensais, comunicação

constante


37

Matriz de Comunicação

Directamente relacionada com a gestão dos Stakeholders, e porque é exigida uma boa

comunicação para saber gerir e endereçar as suas expectativas para o projecto, está também a

gestão da comunicação, isto é, identificar o que comunicar, de que forma, a quem e com que

frequência.

É igualmente importante garantir que a informação é recebida e é eficiente, pelo que a

distribuição da informação deverá também ser considerada, de forma a garantir que cada

stakeholder ou grupo de Stakeholders recebe a informação apropriada no formato apropriado

e com a frequência apropriada.

Na sequência do exposto, está definida a matriz abaixo de comunicação para o projecto. Esta

matriz será mantida e ajustada de acordo com a evolução do projecto:

Tipo De quem Para quem Frequência Meio

Kick-off Gestor de Projecto

Equipa, Sponsor Única Reunião e Acta

de Reunião

Ponto de situação semanal

Equipa Gestor de Projecto

Semanal Reunião

Steering Gestor de Projecto

Sponsor, Equipa Mensal Reunião

Devido às características do Project Server 2010 esta plataforma servirá também de suporte

privilegiado à comunicação entre os membros da Equipa, sendo que, ao longo da fase de

Execução será disponibilizado um site de projecto (workspace) que se constituirá como o

elemento agregador da comunicação de projecto.


38

F. RH

Um projecto não existe sem pessoas. Portanto, para que o projecto seja bem-sucedido é

importante definir uma estrutura formal para que a Equipa envolvida possua um claro

entendimento das suas responsabilidades e autoridades definidas na realização das

actividades do projecto.

Organizational Breakdown Structure

Nesse sentido, um dos primeiros passos é o de estabelecer a Organizational Breakdown

Structure (OBS) do projecto. De acordo com os requisitos de recursos identificados, esta

compreende os perfis de Sponsor, Gestor de Projecto, Analista de Negócio, Web Designer,

User Interface Designer, Developer e Tester, esquematizados abaixo:

Funções e Responsabilidades

A correcta definição e documentação das responsabilidades dos diferentes intervenientes é

um factor crítico de sucesso. O foco na organização e responsabilidades asseguram que:

• As responsabilidades-chave sejam documentadas, percebidas e conhecidas por todos

os Stakeholders do projecto;

• A inter-relação entre a Equipa, Gestor de Projecto e Sponsor seja estabelecida de

forma a maximizar o sucesso do projecto.

Sponsor

Gestor de Projecto

Analista de Negócio

Web Designer

Developer Tester ...

Equ

ipa


39

Assim, para cada um dos Perfis enunciados, atente-se no seu descritivo de funções e

responsabilidades sumárias:

Função Papel Principais Responsabilidades

Sponsor

Responsável máximo do projecto. O seu perfil é o de um gestor com

capacidade de decisão para resolução de qualquer situação que

possa resultar em desvios aos objectivos do projecto

� Assegurar que o projecto recebe prioridade e recursos suficientes

� Disponibilizar recursos financeiros do projecto � Aprovar e aceitar os entregáveis do projecto � Definir as necessidades e objectivos do projecto � Apoiar na resolução de problemas no projecto � Identificar e documentar lições aprendidas

Gestor de Projecto

Responsável pelo sucesso do projecto e por alcançar os objectivos

e resultados do projecto nos vectores tempo, qualidade e custo,

de acordo com o definido. A sua missão é planear, coordenar e gerir os recursos atribuídos ao projecto,

informando periodicamente o Sponsor sobre a evolução e situação

do mesmo e assegurar os respectivos reportings

� Assegurar o sucesso do projecto � Garantir entrega do âmbito definido, com a

qualidade definida e no prazo e orçamento acordado

� Gerir as expectativas dos diferentes Stakeholders, com uma comunicação eficaz e regular e assegurando o envolvimento e comprometimento de todos

� Desenvolver e manter o plano de gestão do projecto

� Estabelecer a estrutura do projecto, organizar a Equipa e definir papéis e responsabilidades no projecto

� Manter a Equipa motivada e disponibilizar formação quando necessário

� Gerir, monitorizar e controlar o progresso do projecto

� Identificar e delinear respostas aos riscos do projecto

� Obter aprovação formal para os entregáveis do projecto

� Identificar e documentar lições aprendidas

Equipa

Responsável pela execução do projecto, bem como por reportar o

progresso das mesmas junto do Gestor de Projecto; deve ainda

contribuir na identificação e resolução de issues e riscos que

possam colocar em causa o normal decurso do projecto

� Fornecer estimativas para o planeamento � Conduzir as actividades de acordo com o

estabelecido no plano de projecto � Desenvolver a documentação técnica do projecto � Identificar e documentar riscos � Identificar e documentar lições aprendidas

De acordo com o seu perfil, note-se que a todos estes estão associadas competências técnicas,

comportamentais e contextuais que se deverão verificar para uma boa execução do projecto.


40

Matriz de Responsabilidades (RACI-VS)

Definidas a WBS e a OBS, deverá estabelecer-se uma matriz de responsabilidades, que permita

cruzar as tarefas definidas com os intervenientes e diferentes responsabilidades.

A matriz de responsabilidades, abaixo representada, é uma importante ferramenta de

comunicação que deve ser apresentada à Equipa desde logo, pois permite estabelecer

expectativas sobre a área de intervenção de cada elemento e definir claramente

responsabilidades. Abaixo, apresenta-se, a título de exemplo, para aquelas actividades que o

Gestor de Projecto pretendeu destacar e esclarecer:

Actividade GP

An

alis

ta

Ne

góci

o

Syst

em

Arc

hit

ect

We

b D

esi

gne

r

Use

r In

terf

ace

De

sign

er

Syst

em

Ad

min

istr

ato

r

De

velo

pe

r Jr

.

De

velo

pe

r Sr

.

Test

er

Tech

nic

al

Wri

ter

PM

O

Man

ager

Clie

nte

Business Case A;R V S

Plano Gestão Projecto

A;R I;C I;C I;C I;C I;C I;C I;C I;C I;C V S

Documento User Interface

V V A;R V S

Ficheiros HTML V V C C R A S

Testes V R;A S

Documentação V C;I A;R S

Entrada em Produção

V I I I I A;R I V I I I S

Actividades de GP A;R I;C I;C I;C I;C I;C I;C I;C I;C I;C V S

R – Responsible – quem executa A – Accountable – quem é o responsável C – Consulted – quem deve ser consultado I – Informed – quem deve ser informado V – Verify – quem verifica S – Sign-off – quem faz o sign-off


41

Aquisição da Equipa

De acordo com a OBS apresentada, e havendo competências internas e especializadas no

âmbito core do projecto, a maioria da Equipa consiste em recursos internos à MMF. Neste

caso, sendo a MMF uma organização fortemente orientada a projectos e estando dotada de

uma estrutura projectizada, a aquisição da Equipa será realizada no início do projecto,

recorrendo à resource pool, identificando quais os melhores recursos aptos a integrar a Equipa

dentre os disponíveis e de acordo com os níveis de alocação previstos para o projecto.

Uma vez que o projecto compreende no seu âmbito a integração com aplicações mobile e esse

não é o core da organização, optou-se por subcontratar, em regime de outsourcing, um

recurso para executar aquelas actividades. O processo de aquisição encontra-se descrito com

maior detalhe no plano de Procurement.


42

Calendarização de Recursos

Considerando o cronograma de projecto planeado, as necessidades de recursos ao longo do

tempo obedecem a períodos de alocação diferenciada. Abaixo, tome-se o exemplo do

histograma de utilização do System Administrator:

Como se verifica, numa primeira abordagem este recurso encontrava-se sobre-alocado. A fim

de resolver as sobrealocações existentes entre os recursos procedeu-se a técnicas de

nivelamento de cargas, como a revisão da sequenciação das tarefas (fast-tracking) e o ajuste

na distribuição das cargas, quando possível, de forma a assegurar não mais do que as 8h

diárias.

Deste modo, numa segunda iteração, a alocação do System Administrator apresentava-se da

seguinte forma:


43

De uma forma geral, a alocação de recursos ao longo dos meses do projecto caracteriza-se

conforme abaixo:


44

Formação

Ao abrigo do projecto, e dado que a Equipa tem o conjunto de skills necessários para o

projecto, não está prevista a necessidade de realização de formação. Porém, se no desenrolar

do projecto e na sequência das avaliações de desempenho, forem identificadas necessidades

de formação, as mesmas serão devidamente apresentadas ao Sponsor do projecto, em virtude

de eventual necessidade de financiamento para a mesma.

Avaliações de Desempenho

De forma a, entre outros, permitir o crescimento pessoal e profissional da Equipa, o Gestor de

Projecto levará a cabo avaliações de desempenho de cada elemento da Equipa, mensalmente.

A avaliação de desempenho assentará na atribuição de uma nota, numa escala de 1 a 4, e na

apresentação dos pontos fortes e a melhorar nas componentes técnicas, comportamentais e

contextuais.

Para esta avaliação de desempenho será ainda utilizado o método STAR, em que é solicitado

ao membro da Equipa que descreva uma Situação (S), indicando a Tarefa (T) levada a cabo

para lidar com a situação, qual a Actividade (A) realizada e qual o Resultado (R) alcançado em

sua consequência. Tal permite que seja o avaliado a identificar uma situação que pretende

destacar e fornece uma visão e avaliação orientada ao resultado, concreta e factual.

Reconhecimento e Recompensas

É hoje sabido e comummente aceite que a motivação das Equipas não provém apenas da

retribuição salarial mas também de outras recompensas e da capacidade de reconhecimento

nos momentos-chave. De resto, “obrigado” é das palavras mais importantes em Gestão de

Projecto.

Apesar das condicionantes do projecto não permitirem amplo espaço para recompensas, estão

planeados alguns momentos e/ou elementos de reconhecimento e recompensa para a Equipa

do projecto, nomeadamente:


45

• Momento de descontracção, vulgo “saída para copos”, após atingir de cada milestone

no Schedule previsto;

• “Foto de família” do projecto na newsletter interna mensal da organização;

• 10 entregas grátis nas compras adquiridas através do website HomeMarket para os

elementos que obtenham pelo menos cinco vezes a nota 4 na avaliação de

desempenho mensal.

Código de Conduta

O código de conduta do projecto constitui um documento fundamental no relacionamento

com e entre a Equipa, pois estabelece um compromisso de orientação ética e profissional na

conduta, além de definir um conjunto de ground rules e comportamentos expectáveis e

desejáveis no seio do projecto, não negociáveis.

Assim, para o projecto Home Market, definiram-se os seguintes valores aos quais a Equipa de

Projecto deve obedecer:

A. Respeito

• Não discriminamos com base em critérios como, entre outros, sexo, raça, idade,

religião, incapacidade, nacionalidade ou orientação sexual

• Tratamos todos os Stakeholders de forma profissional, respeitosa e cordial,

procurando aperfeiçoar os processos de comunicação e de relacionamento

• Agimos de forma cortês, com disponibilidade e atenção a todas as pessoas com que

nos relacionamos, respeitando as diferenças individuais.

• Não prejudicamos a reputação de colegas ou chefias por meio de julgamentos

preconceituosos, falso testemunho, informações não fundamentadas ou qualquer

outro subterfúgio

B. Justiça

• Não usamos o cargo, função, actividade, facilidades, posição e influência com o fim de

obter qualquer favorecimento para nós mesmos ou para outrem


46

C. Honestidade

• Somos transparentes e imparciais nas nossas decisões e honramos os compromissos

que assumimos

• Negociamos de boa-fé

• Fornecemos informações precisas e oportunas

D. Responsabilidade

• Tomamos decisões e agimos com base nos melhores interesses da sociedade, na

segurança pública e no meio ambiente

• Não divulgamos informações estratégicas e de carácter sigiloso da empresa e do

projecto

• Quando nos consideramos não capacitados para executar alguma tarefa, procuramos

os colegas ou Gestor de Projecto a fim de obter os meios para superar essas limitações

E. Solidariedade

• Trabalhamos num clima de integração, companheirismo e colaboração com toda a

Equipa

F. Desenvolvimento Profissional

• Partilhamos lições aprendidas e promovemos uma aprendizagem contínua

• Aprendemos com base nos nossos próprios erros ou de outrem, eliminando as suas

causas e evitando a sua repetição

• Consideramos as críticas construtivas, feitas com transparência e através dos canais

adequados, como uma demonstração de lealdade ao projecto e aos colegas

• Estimulamos a manifestação de ideias, quando alinhadas com os objectivos do

projecto e discutidas em fóruns próprios.


47

G. Risco

Tendo sido feita no Business Case uma primeira análise preliminar dos riscos associados ao

projecto, apresentamos de seguida uma análise mais completa sobre aqueles, incluindo planos

de resposta definidos, pois a gestão do risco é um processo iterativo e que exige monitorização

constante.

A gestão do risco consiste em identificar, analisar, planear e responder, de forma antecipada,

aos eventos de risco - aqui considerado como um evento incerto e com dada probabilidade de

ocorrência e impacto no projecto - que possam ocorrer ao longo do projecto e cujos impactos

se traduzam em efeitos negativos ou positivos (oportunidades) para os objectivos do projecto.

Assim, antes de se avançar para a análise dos riscos identificados, é imperativo que toda a

Equipa tenha o mesmo entendimento sobre as escalas de impacto usadas, sendo por isso

abaixo apresentadas as matrizes de definição de Impacto a considerar no projecto:

Estas escalas têm por objectivo uniformizar a linha de pensamento dos diversos participantes

na análise qualitativa de eventos de risco, para que estes consigam enquadrar, o mais

objectivamente possível, cada um dos eventos numa das classes, tanto de probabilidade como

de impacto. Com estas escalas pretende-se também (e principalmente quando não há

possibilidade de quantificar estes valores para cada evento de risco) possibilitar a sua


48

Muito Elevada 90%

Elevada 70%

Média 50%

Baixo 30%

Muito Baixo 10%

0,1 0,2

0,080,005 0,01 0,02 0,04

0,18 0,36

0,4

0,015 0,03 0,06 0,12 0,24

0,025 0,05

0,8

0,72

0,035 0,07 0,14 0,28 0,56

0,045 0,09

0,2 0,4

Importância (Probabil idade*Impacto)

Probabilidade

Impacto

0,05 0,1

avaliação, atribuindo-lhes um valor que permita efectuar uma comparação entre eles e

ordená-los.

A escala de probabilidade encontra-se dividida, em termos intervalares, em cinco níveis, sendo

o valor das diferentes probabilidades aquele que é utilizado no cálculo do valor do evento de

risco, combinado o impacto e a probabilidade de ocorrência atribuídos. Tal permite uma mais

fácil visualização da concentração dos eventos e o seu posicionamento em cada uma das zonas

identificadas.

De acordo com esta tipificação, obtemos diferentes patamares de criticidade do risco, que

exigirão medidas diferenciadas, nomeadamente, a exigência de uma acção imediata (cor

laranja), do planeamento de uma resposta (cor amarela), ou de documentar e colocar em

watchlist (cor verde).

Estando definidas as escalas a usar para a análise e avaliação qualitativa do risco, apresenta-se

seguidamente, os riscos identificados até à data presente:

49

ID Risco Categoria Probabil

idade Impacto

Estratégia Resposta

Plano Resposta Trigger Owner

1 Falha no orçamento de implementação Gestão Projecto

Baixa Médio Mitigar Controlo semanal de orçamento (CPI e EAC); revisão baseline

CPI < 0,8 GP

2 Falta de apoio e envolvimento da alta direcção

Gestão Stakeholders

Baixa Elevado Mitigar Reuniões mensais de evolução de projecto; comunicação constante

Ausência em reuniões; ausência de feedback

GP

3 Perda de prioridade do projecto na organização

Gestão Projecto

Baixa Elevado Mitigar Apresentação de resultados mensais; comunicação constante com Sponsor

Desvio de recursos para outros projectos

GP

4 Envolvimento insuficiente dos utilizadores na implementação do sistema


Média Elevado Mitigar Convocar para reuniões

Críticas infundamentadas; resistência à implementação

GP

5 Falta de integração e/ou confiança entre o implementador e o cliente


Baixa Médio Mitigar Pontos de situação semanais

Críticas infundamentadas; resistência à implementação

GP

6 Mudanças nos requisitos do sistema durante o projecto

Gestão Projecto

Elevada Elevado Mitigar

Reuniões de esclarecimento de requisitos; monitorização do plano de requisitos; controlo da gestão de alterações

Submissão de pedido de Alteração de Requisitos

Analista Negócio

7 Falha na estimativa dos prazos de implementação

Gestão Projecto

Média Médio Mitigar Controlo semanal de Schedule (SPI e EDAC); crashing e fast tracking do calendário

SPI < 0,8 GP

8 Falta de qualidade dos dados a integrar Tecnologia Média Elevado Mitigar Solicitação prévia de lista de preços e/ou recolha de lista por colaboradores internos

Limitação no mapeamento na fase de Integração (API)

System Admin

9 Arquitectura inadequada da implementação

Tecnologia Média Elevado Mitigar Testes sobre diferentes versões da arquitectura

Peer review apresenta dúvidas

System Archit.

10 Testes do sistema pouco efectivos Tecnologia Média Elevado Mitigar Caderno de testes com critérios de aceitação bem definidos

Erro no deploy para ambiente de testes

Tester

50

Para uma efectiva resposta aos riscos identificados serão tidas em conta técnicas como o

Fishbone Diagram, esquematizado abaixo, ou a técnica dos 5 Whys.

Falha totalda aplicação

Complexidade -Definição doProjecto

AmbienteHardware

Ambiente/ Envolvente -Competências Especializadas

AmbienteSoftware

Análise deRequisitos Pobre

Inexistência detestes de aceitação

Falta de exposiçãoao mundo real

Formaçãodesadequada

Hardware da aplicaçãonão suportado

Teste de sistemadiferente da produção

Uso de versãodiferente

Uso de dadosdiferentes

Ask Why 5 Times (Exemplo)

Descrição do Problema: Os utilizadores estão insatisfeitos com a aplicação disponibilizada.

1 Porque é que os utilizadores estão insatisfeitos com a aplicação?

Porque a aplicação não contém algumas funcionalidades importantes.

2 Porque é que a aplicação não contém algumas funcionalidades importantes?

A aplicação foi desenvolvida de acordo com requisitos que as não contemplavam.

3 Porque é que as especificações não contemplavam as funcionalidades importantes?

Porque os utilizadores não participaram na definição de especificações.

4 Porque é que os utilizadores não participaram na definição de especificações?

Porque não estavam integrados na Equipa de Projecto.

5 Porque é que os utilizadores não estavam integrados na Equipa de Projecto?

Porque o Plano de Gestão do Projecto não foi bem definido.

Causa: Plano de Gestão do Projecto mal definido / falhas na definição do projecto.


51

H. Fornecedores

O âmbito do projecto HomeMarket é favorecido no sentido em que assenta sobre as

competências core internas à MMF. Porém, no que respeita às aplicações mobile, esta não é a

especialização da empresa, que viu na subcontratação desta componente a melhor opção a

tomar.

Assim, para essa parte do âmbito foi realizado um contrato de preço fechado no valor de

12.000€, com uma empresa especializada no sector, a Mais Mobile.

Esta foi considerado o tipo de contrato mais adequado uma vez que o âmbito é conhecido e

está bem definido.


52

Identificar

Avaliar

Decidir

Implementar

I. Gestão de Alterações

Muitas vezes os projectos falham devido a um ineficiente processo de gestão e controlo de

alterações. Assim, porque as alterações são inevitáveis, esta temática assume especial

preponderância na gestão do projecto HomeMarket.

São os seguintes os objectivos do sistema de controlo de alterações implementado no

projecto:

• Gerir os Pedidos de Alteração, de modo a manter o âmbito do projecto controlado;

• Garantir a formalização dos Pedidos de Alteração;

• Garantir a avaliação do impacto de cada Pedido de Alteração nos objectivos do

projecto – âmbito, prazo, recursos, custo, qualidade e risco;

• Garantir que o impacto das alterações pedidas é efectivamente compreendido pelos

principais Stakeholders, bem como devidamente documentado, gerido e

implementado caso seja aceite;

• Garantir que cada Pedido de Alteração é aceite, rejeitado ou diferido pelo responsável

apropriado;

• Assegurar a implementação ordenada e controlada de cada alteração aceite.

Assim, cada Pedido de Alteração deverá fluir através de uma sequência de estados, sendo de

destacar o papel do Change Control Board definido no processo de aprovação/rejeição da

alteração.


53

FASE III – REALIZAÇÃO E CONTROLO DO PROJECTO


54

1. Cenários de Execução

O sucesso de um projecto depende da forma como os gestores escolhem a melhor estratégia

para atingir os objectivos propostos.

A MMF sabe pela sua experiência que, no dia-a-dia do projecto, será necessário tomar

decisões baseadas em dados rigorosos, factuais e objectivos, de forma célere e por isso

utilizará neste projecto um sistema de reporte de métricas Earned Value Management (EVM)

que permite uma leitura simples e clara em tempo real do estado de performance do projecto,

informação necessária para a tomada de decisões de gestão baseadas em indicadores reais.

O termo “Earned Value” é um conceito muito valioso nos dias que correm e afirmando-se

como uma metodologia indispensável na área de Gestão de Projecto.

A gestão de projectos fundada na técnica EVM, única técnica capaz de integrar âmbito, custo e

tempo, abona e dota o gestor de projecto de respostas absolutamente relevantes para a

condução do projecto até aos seus objectivos:

• Qual o progresso global do projecto?

• Qual o desvio de prazo até à data actual?

• Se continuarmos com esta velocidade quando é que vamos terminar?

• Qual o desvio de orçamento verificado para o progresso realizado?

• Qual será o custo final do projecto?

De forma a obtermos a resposta a estas questões, o registo do progresso do projecto tem sido

actualizado no Project Server, com uma periodicidade semanal, decorrente do preenchimento

de timesheets pelos membros da equipa de projecto. Esta granularidade permitirá um

acompanhamento e controlo dos tempos de execução adequados, privilegiando com especial

enfoque os indicadores de status como o Cost Performance Index (CPI) e Schedule Performance

Index (SPI), mas também fornecendo indicadores de progresso e de forecast.

Assim, atente-se para os seguintes 2 cenários de execução, com status dates diferentes:


55

Status date: 06-08-2012

SPI: 1,01

CPI: 0,98

% Progresso: 19%

À data de 06-08, iniciava-se a fase de Análise, sendo que as anteriores apresentaram um

comportamento igual ao planeado, culminando num indicador de velocidade positivo, de 1,01

e num indicador de produtividade muito próximo do desejável, estando a ser influenciado peta

tarefa de QA/QC onde se registou um custo superior ao planeado por via de mais horas

necessárias do que aquelas que estavam previstas. Na generalidade, o projecto apresenta uma

% de completude de sensivelmente 19% e bons indicadores de EVM.


56

Status date: 15-10-2012

SPI: 0,73

CPI: 1,86

% Progresso: 61%

Num cenário posterior, à status date de 15-10 e com o projecto já a entrar nas suas fases finais

de execução, assiste-se a um SPI de 0,73, o que significa algum atraso face ao planeado, como

se verifica facilmente nas fases de Design e de Implementação. Quanto ao CPI, estendendo a

tendência que parecia emergir no cenário anteriormente apresentado, encontra-se a 1,86, o

que significa uma poupança de custos assinalável, cujo maior contributo provém das fases de

Arquitectura e Design.


57

De forma tabelar podemos observar essa mesma informação abaixo:


58

Uma outra forma bastante intuitiva de realizar a monitorização e controlo pelo EVM é sob a

forma gráfica, assim ilustrada:

Observe-se ainda os indicadores de forecast obtidos:


59

De acordo com estes, se continuarmos à velocidade e produtividade actual, terminaremos o

projecto com um custo de 51.758,92€ (EAC), bastante favorável face ao orçamento previsto de

96.495€ (BAC), e com uma duração de aproximadamente 147 dias (EDAC), o que representa

um atraso face aos 107 dias estimados (DAC) e que levaria a que o projecto terminasse a 08-

01-2013 em vez de 13-11-2012.

Poder desde logo obter indicadores previsionais para o futuro através de EVM, permite à

Gestão do Projecto endereçar muito mais rapidamente e com indicadores factuais e números

assertivos a evolução do projecto e assim empreender as medidas necessárias para corrigir a

mesma.


60

FASE IV – ENCERRAMENTO DO PROJECTO


61

1. Termo de Encerramento

Findo o projecto, deverá aferir-se se todos os entregáveis foram aceites e se foram

endereçadas as expectativas do Cliente e demais Stakeholders. Uma vez que a validação e

entrega de aceitáveis foi sendo feita gradualmente e sempre privilegiando um

acompanhamento constante do projecto junto do Cliente, conseguiu terminar-se o projecto

com sucesso, apesar de alguns desvios, a título de simulação, que abaixo se indicam.

Baseline Real Variância

Data Inicio 18-06-2012 18-06-2012 0 dias Data Fim 13-11-2012 18-12-2012 25 dias Duração 107 dias 132 dias - 25 dias Custo 96.495 € 70.328,54 € 26.166,46 €

Não obstante o desvio ao nível de duração – essencialmente derivado de ligeiros atrasos nas

fases de Implementação e Verificação e um pedido de alteração implementado - o site ficou

disponível antes da deadline que tinha sido apontada. No que respeita ao custo do projecto, o

custo ficou abaixo do planeado, o que constitui um facto muito positivo, em virtude,

sobretudo, de poupanças realizadas nas fases de Arquitectura e Design.

Porém, o sucesso de um projecto é definido pelo Cliente. Assim, por forma a concluir sobre a

percepção de qualidade e satisfação do Cliente foi entregue para assinatura o Termo de

Encerramento e aceitação do Projecto e realizada breve entrevista com o mesmo na sessão de

encerramento, de onde se obteve um feedback muito satisfatório.

2. Lições Aprendidas

O identificar de Lições Aprendidas ao longo do projecto é de uma importância crucial, pois

permite que a Equipa se foque no que correu bem e menos bem, de modo a que em futuros

projectos boas práticas possam ser replicadas e erros não se voltem a cometer.

Enquadrada na sessão de encerramento, foram compilados na tabela abaixo os variados

feedbacks sobre lições aprendidas pela Equipa:


62

Tema Como foi feito Lição Aprendida/ Recomendação para futuro

Schedule Verificou-se que as estimativas fornecidas para algumas fases não foram as mais adequadas

Para estimativa sobre as fases mais críticas do projecto, solicitar expert judgement de recursos mais experientes

Budget Verificou-se uma poupança de budget, derivado de uma estimativa demasiado pessimista

Rever a percentagem alocada à reserva de contingência

Sponsorship Envolvimento permanente e alto patrocínio pelo Sponsor

Replicar no futuro

Gestão de Fornecedores

A gestão de fornecedores decorreu sem issues. Todavia, no futuro poderá pensar-se outros regimes de contratação

Analisar com mais profundidade o processo de selecção de fornecedores e regime de contratação (ex: outsourcing); fornecedor com nota positiva para futuros projectos

Gestão de Stakeholders

Os Stakeholders foram continuamente monitorizados e não se registou qualquer issue neste domínio

Replicar no futuro

Gestão da Equipa

A Equipa foi empenhada e manifestou-se motivada mesmo nos picos de trabalho mais intensos; o Developer Jr mostrou explicitamente interesse em adquirir competências ao nível mobile para o futuro

Equipa recomendável para projectos semelhantes futuros; verificar com Dep. Formação oferta de formação ao nível de Desenvolvimento em Mobile

Gestão do Risco

Verificou-se um plano efectivo de resposta aos riscos e a Equipa contribuiu activamente na sua identificação. Porém, haverá espaço para melhorias na identificação de triggers que permitam maior tempo de resposta

Apurar os triggers de próximos projectos; definir prazos de implementação dos planos de resposta

Gestão de Alterações

Todos os pedidos de alteração seguiram o processo definido, tendo havido um pedido de alteração com impacto pouco significativo implementado

Continuar a usar e difundir o processo de gestão de alterações; ressalvar a importância de todos os pedidos cumprirem o processo

Metodologia

Foi utilizada a metodologia da empresa, baseada nas boas práticas IPMA e PMI. Alguns elementos da Equipa consideraram uma metodologia muito “pesada” para o projecto, sugerindo uma combinação de práticas SCRUM para projectos semelhantes futuros

Apurar o tailoring da metodologia ao tipo de projecto; estudar a aplicabilidade de metodologias ágeis em projectos futuros


63

Conclusão

A aprendizagem por via da experiência constitui uma das mais enriquecedoras formas de

aprender e, chegada esta página de conclusões, podemos agora afirmar que com este trabalho

conseguimos amplamente atingir esse objectivo.

Como lições aprendidas pelo Grupo na realização deste trabalho de planeamento e simulação

da gestão de um projecto, do início ao fim, apontamos as seguintes, para utilização em

projectos vindouros e como recomendações para outros colegas:

� A análise de benefícios não deve ser descurada: deve justificar claramente a existência

do projecto;

� Um projecto é mais do que um plano de projecto no MS Project: existem todo um

conjunto de práticas, técnicas e ferramentas que devem ser ponderadas para bem-

fazer acontecer o previsto no plano;

� Um projecto envolve sobretudo saber equilibrar os vários objectivos conflituantes que

sempre se verificam; neste trabalho, a relação qualidade/tempo foi sobretudo

complexa de gerir, pelo que futuros trabalhos exigirão um foco no essencial, a garantir,

e só depois incrementos graduais, na lógica de melhoria contínua;

� Um projecto pode não ter um plano mas exige um planeamento. Não devemos ceder à

tentação de fazer tudo de uma vez, mas antes sequenciar fases e actividades e

prioritizar a sua realização. “How do you eat na elephant? One bite at a time.”;

� Não existem metodologias óptimas: a metodologia utilizada deve ser adaptada

(tailoring) ao ambiente, cultura organizacional e tipo de projecto em causa, e pode

inclusivamente beber de várias fontes;

� Um projecto é também alinhar expectativas, sobretudo dos Stakeholders-chave; uma

forma de garantir o sucesso do projecto é ter várias entregas e aceitações parceladas

junto do Cliente (neste caso, o Professor) em vez de uma entrega final total; não ter

medo de questionar o Porquê – para alinhar expectativas e definir os requisitos é das

palavras mais utilizadas pelo Gestor de Projecto;

� O trabalho em Equipa é sempre mais valioso e enriquecedor do que um trabalho

individual: aprendemos uns com os outros e, juntos, todos aprendemos.

Documents

Gestão de Projecto - HomeMarket