1. Trabalho de Grupo – Gestão de Projectos
[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
1
2. Trabalho de Grupo – Gestão de Projectos
Í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
2
3. Trabalho de Grupo – Gestão de Projectos
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.
3
4. Trabalho de Grupo – Gestão de Projectos
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
4
5. Trabalho de Grupo – Gestão de Projectos
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.
5
6. Trabalho de Grupo – Gestão de Projectos
FASE I – INICIAÇÃO DO PROJECTO
6
7. Trabalho de Grupo – Gestão de Projectos
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.
7
8. Trabalho de Grupo – Gestão de Projectos
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)
8
9. Trabalho de Grupo – Gestão de Projectos
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.
Continente
Online
Home
Market
Jumbo Pingo Doce
Online Online
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.
9
10. Trabalho de Grupo – Gestão de Projectos
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.
Ciclo de Vida do Produto 5 anos
Inflação 1,75% ano
Financeiros 223.230,00 €
Frequência/Ano
Benefício +/- Unidade Frequência (Número, %) Métrica Descrição da métrica Média
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 €
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€.
10
11. Trabalho de Grupo – Gestão de Projectos
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:
Tx Interesse = 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
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.
11
12. Trabalho de Grupo – Gestão de Projectos
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:
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
Estes riscos serão mais amplamente explorados e monitorizados durante a execução do
projecto, no plano de gestão do Risco.
12
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.
13
14. Trabalho de Grupo – Gestão de Projectos
FASE II – ESTRUTURAÇÃO DO PROJECTO
14
15. Trabalho de Grupo – Gestão de Projectos
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)
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.
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
15
16. Trabalho de Grupo – Gestão de Projectos
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
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
O site tem que estar disponível antes de 15 de Março, dia
Cronograma
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
Disponibilidade das cadeias de hipermercados para permitir o
Acesso a Dados Externos
acesso em tempo real e directamente aos preços de venda
Disponibilidade da Equipa de acordo com as alocações
Disponibilidade da Equipa
planeadas
Fornecedores Domínio na implementação de soluções mobile
Disponibilidade do Cliente para validações e aceitação de
Disponibilidade do Cliente
entregáveis
16
17. Trabalho de Grupo – Gestão de Projectos
8. MODELO DE GOVERNO <Identifica momentos de controlo no projecto.>
Modelo de Governo Informação
Ponto de Situação com Periodicidade Semanal
Equipa Dia / Hora Sextas-feiras / 12h-13h
Periodicidade Mensal
Reunião de Steering
Dia / Hora Última Quinta-feira / 16h-18h
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.
17
18. Trabalho de Grupo – Gestão de Projectos
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
18
19. Trabalho de Grupo – Gestão de Projectos
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
19
20. WBS do Projecto
0. Projecto Home
Market
4 Monitorização e
1. Iniciação 2. Estruturação 3. Execução 5 Encerramento
Controlo
5.1 Termo
1.1 Business Case 2.1 Plano Projecto 3.1 Análise 3.2 Design 3.3 Implementação 3.4 Verificação 3.5 Documentação 3.6 Rollout
Encerramento
1.2 Termo de 3.1.1 3.4.1 Caderno 3.5.1 Manual 3.6.1 Entrada 5.2 Lições
2.2 Plano GP 3.2.1 Arquitectura 3.3.1 Configuração
Abertura Especificações Testes Utilizador Produção Aprendidas
3.5.2 Manual
2.3 Reunião kikc-off 3.2.2 User Interface 3.3.2 Integração 3.4.2 Testes
Administração
3.2.3 Design 3.3.3 Base de Dados
3.3.4 Core
3.3.5 Interface
20
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
Documento que justifica a realização Conforme template da
1.1 Business Case do projecto, viabilidade e sua empresa; validado pelo PMO e
exequibilidade disponível e aceite pelo Cliente
Documento que formaliza a existência Conforme template da
1.2 Termo de Abertura do projecto e autoriza o Gestor de empresa; validado pelo PMO;
Projecto a iniciar o projecto assinado pelo Sponsor
2 Estruturação
Plano que apresenta a estrutura de
Conforme template MS Project
actividades, sequenciação, recursos,
2.1 Plano de Projecto da empresa; validado pelo PMO;
etc, e que é utilizado para
disponível e aceite pelo Cliente
planeamento e controlo do projecto
Conjunto de documentos que define
como o projecto será planeado, gerido Conforme template da
Plano de Gestão de
2.2 e controlado nas suas diferentes empresa; validado pelo PMO;
Projecto
componentes (âmbito, tempo, custo, disponível e aceite pelo Cliente
qualidade, comunicação, etc)
3 Execução
3.1 Análise
O caderno de especificações detalhe
Conforme requisitos levantados;
3.1.1 Caderno de Especificações requisitos técnicos e de negócio da
disponível e aceite pelo Cliente
solução
3.2 Design
3.2.1 Arquitetura
Incluir especificações técnicas e
Este documento especifica a
3.2.1.1 Documento de Arquitetura diagramas de fluxos de dados;
arquitetura da solução a implementar.
disponível e aceite pelo Cliente
3.2.2 User Interface
Incluir wireframes finais
O documento de User Interface validados pelo cliente, assim
3.2.2.1 Documento User Interface define a disposição da interface de como o relatório de testes de
utilizador usabilidade realizados;
disponível e aceite pelo Cliente
3.2.3 Design
Conforme Documento de User
Ficheiro vectorial produzido pelo
3.2.3.1 Ficheiros PSD Interface; ficheiros disponíveis e
designer
template aceite pelo Cliente
Ficheiros HTML produzidos com base Conforme ficheiros PSD;
3.2.3.2 Ficheiros HTML
nos ficheiros PSD Ficheiros HTML disponíveis e
21
22. Trabalho de Grupo – Gestão de Projectos
validados pela W3C
3.3 Implementação
Nesta fase deverão ser configurados Conforme Documento de
3.3.1 Configuração os vários ambientes de Arquitectura; Ambientes
desenvolvimento disponíveis e configurados
Inícios da codificação da solução, os
serviços de integração serão
desenvolvidos nesta fase. São estes
3.3.2 Integração API’s disponíveis
serviços que permitirão ao
HomeMarket comunicar com
entidades externas (supermercados)
Definição do modelo de dados a
Base de Dados utilizar de acordo com os requisitos e Script de base de dados
3.3.3
arquitetura. Serão entregues os disponível e aceite pelo Cliente
scripts para criação da base de dados
Implementação das principais Ficheiros de código fonte
3.3.4 Core
funcionalidades do negócio aceites pela Qualidade
Implementação dos ecrãs da aplicação
que vão comunicar diretamente com Plano de interfaces disponível e
3.3.5 Interface
as funcionalidades de negócio aprovado pelo Cliente
implementadas no core
3.4 Verificação
Construção dos casos de testes, Lista da associação entre os
3.4.1 Caderno de Testes
mapeados aos requisitos identificados requisitos e os casos de teste
Conformidade com caderno de
Realização de testes, de acordo com
3.4.2 Testes testes e relatórios da execução
caderno de testes
dos testes
3.5 Documentação
Documento produzido para auxiliar o Conforme template disponível
3.5.1 Manual do Utilizador utilizador durante a utilização do na empresa; disponível e
Homemarket aprovado pelo Cliente
Documento produzido para ser Conforme template disponível
3.5.2 Manual de Administração utilizado pelos administradores do site na empresa; disponível e
(backoffice) aprovado pelo Cliente
Fase final em que o HomeMarket é Plano de rollout entregue e
3.6 Rollout disponibilizado aos primeiros aceite pelo cliente; relatório de
utilizadores ocorrências
4 Monitorização e Controlo
Conforme templates e
Inclui reuniões, steering, reporting,
4.1 Actividades de GP metodologia disponível na
etc
empresa; validado pelo PMO
5 Encerramento
Inclui tabela de variâncias;
Documento que formaliza o fecho do conforme template disponível
5.1 Termo de Encerramento
projecto na empresa; validado pelo PMO;
disponível e aceite pelo Cliente
Conforme template disponível
Documento que registas as lições na empresa; validado pelo PMO;
5.2 Lições Aprendidas
aprendidas com o projecto inclui contributos de toda a
Equipa
22
23. Trabalho de Grupo – Gestão de Projectos
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.
23
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:
27
29. Trabalho de Grupo – Gestão de Projectos
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€
29
30. Trabalho de Grupo – Gestão de Projectos
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.
30
31. Trabalho de Grupo – Gestão de Projectos
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:
Plan
Act Qualidade Do
Check
31
32. Trabalho de Grupo – Gestão de Projectos
• 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:
32
33. Trabalho de Grupo – Gestão de Projectos
Medida Métrica
Coerência entre os requisitos levantados inicialmente e as
Funcionalidade
funcionalidades efectivamente entregue.
Rácio entre número de linhas de código e erros
Confiabilidade detectados. Rácio entre erros levantados e corrigidos na
fase de testes.
Coerência entre os ecrãs definidos na fase de design e os
Usabilidade
ecrãs que foram efectivamente implementados.
Análise da performance na solução. Eficiência na
Eficiência
resolução do problema apresentado inicialmente.
Rácio entre número de linhas de código e
Manutenibilidade funcionalidades. Analisar a complexidade do código
produzido, utilizando ferramentas para métricas.
Analisar a portabilidade da solução entre os vários
Portabilidade
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.
33
34. Trabalho de Grupo – Gestão de Projectos
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.
34
35. Trabalho de Grupo – Gestão de Projectos
Nesse sentido, para o projecto HomeMarket, foram identificados os Stakeholders abaixo:
Nome Organização Papel Poder Interesse Estratégia
Elevado Elevado Gerir
Eng. AA MMF Sponsor
Poder Interesse Activamente
Deco Elevado Elevado Gerir
Dr. BB Cliente
Proteste Poder Interesse Activamente
Moderado Moderado Manter
CC Continente Participante
Poder Interesse Satisfeito
Moderado Moderado Manter
DD Pingo Doce Participante
Poder Interesse Satisfeito
Moderado Moderado Manter
EE Jumbo Participante
Poder Interesse Satisfeito
Develop. Sr. Reduzido Moderado Manter
FF Mais Mobile
Fornecedor Poder Interesse Informado
Develop. Jr. Reduzido Reduzido
FI Mais Mobile Monitorizar
Fornecedor Poder Interesse
Deco Elevado Reduzido Manter
ADV Dep. Legal
Proteste Poder Interesse 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:
DD AA
BB
Manter CC Gerir
Satisfeito Activamente
ADV
Poder
EE
Monitorizar Manter
Informado
FI
FF
Interesse
35
36. Trabalho de Grupo – Gestão de Projectos
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
Reuniões mensais, comunicação constante, almoços
Dr. BB Apoiante
semanais
Desenvolver relação de confiança com a cadeia de
supermercado, mantendo informado da evolução do
CC Neutro
projecto, convidar para acção de team building do
projecto com storytelling de apresentação benefícios
Desenvolver relação de confiança com a cadeia de
supermercado, mantendo informado da evolução do
DD Bloqueante projecto, convidar para acção de team building do
projecto com storytelling de apresentação benefícios,
marcar almoço
Desenvolver relação de confiança com a cadeia de
supermercado, mantendo informado da evolução do
EE Apoiante
projecto, convidar para acção de team building do
projecto com storytelling de apresentação benefícios
Envolver com Equipa interna, convidar para acções de
FF Neutro
comemoração milestones
Envolver com Equipa interna, convidar para acções de
FI Apoiante
comemoração milestones
Manter a boa relação entre as marcas/supermercados
ADV Apoiante presentes no sistema, Reuniões mensais, comunicação
constante
36
37. Trabalho de Grupo – Gestão de Projectos
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
Gestor de Reunião e Acta
Kick-off Equipa, Sponsor Única
Projecto de Reunião
Ponto de
Gestor de
situação Equipa Semanal Reunião
Projecto
semanal
Gestor de
Steering Sponsor, Equipa Mensal Reunião
Projecto
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.
37
38. Trabalho de Grupo – Gestão de Projectos
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:
Sponsor
Gestor de
Projecto
Equipa
Analista de Web
Developer Tester ...
Negócio Designer
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.
38
39. Trabalho de Grupo – Gestão de Projectos
Assim, para cada um dos Perfis enunciados, atente-se no seu descritivo de funções e
responsabilidades sumárias:
Função Papel Principais Responsabilidades
Assegurar que o projecto recebe prioridade e
Responsável máximo do projecto. O
recursos suficientes
seu perfil é o de um gestor com
Disponibilizar recursos financeiros do projecto
capacidade de decisão para
Sponsor Aprovar e aceitar os entregáveis do projecto
resolução de qualquer situação que
Definir as necessidades e objectivos do projecto
possa resultar em desvios aos
Apoiar na resolução de problemas no projecto
objectivos do projecto
Identificar e documentar lições aprendidas
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
Responsável pelo sucesso do
assegurando o envolvimento e
projecto e por alcançar os objectivos
comprometimento de todos
e resultados do projecto nos
Desenvolver e manter o plano de gestão do
vectores tempo, qualidade e custo,
projecto
de acordo com o definido. A sua
Gestor de Estabelecer a estrutura do projecto, organizar a
missão é planear, coordenar e gerir
Projecto Equipa e definir papéis e responsabilidades no
os recursos atribuídos ao projecto,
projecto
informando periodicamente o
Manter a Equipa motivada e disponibilizar
Sponsor sobre a evolução e situação
formação quando necessário
do mesmo e assegurar os
Gerir, monitorizar e controlar o progresso do
respectivos reportings
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
Responsável pela execução do
Fornecer estimativas para o planeamento
projecto, bem como por reportar o
Conduzir as actividades de acordo com o
progresso das mesmas junto do
estabelecido no plano de projecto
Gestor de Projecto; deve ainda
Equipa Desenvolver a documentação técnica do projecto
contribuir na identificação e
Identificar e documentar riscos
resolução de issues e riscos que
Identificar e documentar lições aprendidas
possam colocar em causa o normal
decurso do projecto
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.
39
40. Trabalho de Grupo – Gestão de Projectos
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:
User Interface
Administrator
Web Designer
Developer Sr.
Developer Jr.
Technical
Manager
Architect
Designer
Analista
Negócio
Cliente
Writer
System
System
Tester
PMO
GP
Actividade
Business Case A;R V S
Plano Gestão
A;R I;C I;C I;C I;C I;C I;C I;C I;C I;C V S
Projecto
Documento User
V V A;R V S
Interface
Ficheiros HTML V V C C R A S
Testes V R;A S
Documentação V C;I A;R S
Entrada em
V I I I I A;R I V I I I S
Produção
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
40
41. Trabalho de Grupo – Gestão de Projectos
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.
41
42. Trabalho de Grupo – Gestão de Projectos
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:
42
43. Trabalho de Grupo – Gestão de Projectos
De uma forma geral, a alocação de recursos ao longo dos meses do projecto caracteriza-se
conforme abaixo:
43
44. Trabalho de Grupo – Gestão de Projectos
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:
44
45. Trabalho de Grupo – Gestão de Projectos
• 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
45
46. Trabalho de Grupo – Gestão de Projectos
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.
46
47. Trabalho de Grupo – Gestão de Projectos
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
47
48. Trabalho de Grupo – Gestão de Projectos
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.
Importância
(Probabilidade*Impacto)
Impacto
Probabilidade 0,05 0,1 0,2 0,4 0,8
Muito Elevada 90% 0,045 0,09 0,18 0,36 0,72
Elevada 70% 0,035 0,07 0,14 0,28 0,56
Média 50% 0,025 0,05 0,1 0,2 0,4
Baixo 30% 0,015 0,03 0,06 0,12 0,24
Muito Baixo 10% 0,005 0,01 0,02 0,04 0,08
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:
48
49. Probabil Estratégia
ID Risco Categoria Impacto Plano Resposta Trigger Owner
idade Resposta
Gestão Controlo semanal de orçamento
1 Falha no orçamento de implementação Baixa Médio Mitigar CPI < 0,8 GP
Projecto (CPI e EAC); revisão baseline
Ausência em
Falta de apoio e envolvimento da alta Gestão Reuniões mensais de evolução de
2 Baixa Elevado Mitigar reuniões; ausência de GP
direcção Stakeholders projecto; comunicação constante
feedback
Apresentação de resultados
Perda de prioridade do projecto na Gestão Desvio de recursos
3 Baixa Elevado Mitigar mensais; comunicação constante GP
organização Projecto para outros projectos
com Sponsor
Críticas
Envolvimento insuficiente dos
Gestão infundamentadas;
4 utilizadores na implementação do Média Elevado Mitigar Convocar para reuniões GP
Stakeholders resistência à
sistema
implementação
Críticas
Falta de integração e/ou confiança Gestão infundamentadas;
5 Baixa Médio Mitigar Pontos de situação semanais GP
entre o implementador e o cliente Stakeholders resistência à
implementação
Reuniões de esclarecimento de
Submissão de pedido
Mudanças nos requisitos do sistema Gestão requisitos; monitorização do Analista
6 Elevada Elevado Mitigar de Alteração de
durante o projecto Projecto plano de requisitos; controlo da Negócio
Requisitos
gestão de alterações
Controlo semanal de Schedule
Falha na estimativa dos prazos de Gestão
7 Média Médio Mitigar (SPI e EDAC); crashing e fast SPI < 0,8 GP
implementação Projecto
tracking do calendário
Solicitação prévia de lista de Limitação no
System
8 Falta de qualidade dos dados a integrar Tecnologia Média Elevado Mitigar preços e/ou recolha de lista por mapeamento na fase
Admin
colaboradores internos de Integração (API)
Arquitectura inadequada da Testes sobre diferentes versões Peer review System
9 Tecnologia Média Elevado Mitigar
implementação da arquitectura apresenta dúvidas Archit.
Caderno de testes com critérios Erro no deploy para
10 Testes do sistema pouco efectivos Tecnologia Média Elevado Mitigar Tester
de aceitação bem definidos ambiente de testes
49