Gerenciamento de projetos de sistemas 2012.1

Curriculum

Adm. Marcelo Augusto M. Barbosa

•  Graduado – Administração -‐ FSL;

•  Mestre em Desenvolvimento Regional e Meio Ambiente -‐ UNIR;

•  Especialista -‐ MBA -‐ Gestão Empresarial Estratégica -‐ Educon/USP;

•  Especialista em Metodologia do Ensino – FSL;

• Servidor Público de Carreira – IPAM (1991);

•  Professor (2004)

EMENTA Conceitos básicos sobre gerenciamento de projetos, Perfil do Gerente de Projetos, Ferramentas para o Gerenciamento de Projetos.

OBJETIVO GERAL O aluno do curso de Sistemas para Internet deverá ao final do módulo saber aplicar o aprendizado das ferramentas, conceitos e filosofias em aLvidades profissionais de gestão de projetos de sistema e de soNwares para Internet.

OBJETIVO ESPECÍFICOS a)  Compreender as fases do gerenciamento de projetos com base na filosofia do InsLtuto

de Gerenciamento de Projetos (PMI); •  Analisar e aplicar a filosofia do PMI na gestão do: Escopo, Tempo, Custo,

Qualidade, RH (pessoas), Aquisições, Integração, Risco, Comunicação de projeto de sistemas de soNwares;

CONTEÚDO PROGRAMÁTICO DA DISCIPLINA 1.   Premissas do Gerenciamento de Projetos

•  Atributos de um Projeto •  Obje%vo; condução; recursos; tempo; cliente; singularidade; incerteza.

•  Fatores limitantes para o sucesso e para o próprio gerenciamento de um projeto. •  Custo; cronograma (tempo); cliente (sa%sfação); escopo.

•  Ciclo de vida de um Projeto •  Iden%ficação da necessidade; Desenvolvimento da proposta; Implementação da solução para a necessidade; conclusão.

•  O processo de gestão: os sete passos para o plano base •  Definição dos obje%vos; divisão e subdivisão do escopo em pacotes de trabalhos – EAP (estrutura analí%ca de projetos); definição de a%vidades específicas do projeto; ilustração gráfica do projeto; es%ma%va de tempos para as a%vidades de projetos; es%ma%va de custos; calculo do tempo e orçamento

2. Gerenciamento de Projetos de Sistemas de SoNware pela Filosofia PMI

•  Processo de Gerenciamento de Projeto •  Processo de Iniciação; Processo de Planejamento; Processo de Execução; Processo de Encerramento.

•  (1) Integração do Gerenciamento do Projeto •  Termo de abertura; Declaração preliminar de escopo; Desenvolver o plano de gerenciamento de projetos; Orientar a gerenciar a execução do projeto; Monitorar e controlar o trabalho do projeto; Controle integrado de mudanças, encerrar o projeto.

•  (2) Gerenciamento do escopo do projeto •  Planejamento do escopo; definição do escopo; criação da EAP; verificação do escopo.

•  (3) Gerenciamento do Tempo do Projeto •  Definição da a%vidade; sequenciamento de a%vidades; es%ma%vas de recursos das a%vidades; es%ma%va de duração das a%vidades; desenvolvimento do cronograma; controle do cronograma.


•  (4) Gerenciamento dos custos do projeto •  Es%ma%vas de custos; orçamento; controle de custos

•  (5) Gerenciamento da qualidade do projeto •  Planejamento da qualidade; Realização da garan%a da qualidade

•  (6) Gerenciamento de RH do projeto •  Planejamento de RH; contratação ou mobilização da equipe de projeto; desenvolvimento da equipe de projeto; gerenciamento da equipe de projeto.

•  (7) Gerenciamento do das Comunicações do projeto •  Planejamento da comunicação; distribuição das informações; relatório de desempenho; gerenciamento das partes interessadas.

•  (8) Gerenciamento dos riscos em projeto •  Planejamento de gerenciamento de riscos; iden%ficação de riscos; análise qualita%va de riscos; análise quan%ta%va dos riscos; planejamento de repostas a riscos.

•  (9) Gerenciamento de aquisições em projetos •  Planejamento

3. Seminário sobre Gestão de Projetos com base em Ferramentas Ágeis Temas

•  Agile Project Management (APM) -‐ Gerenciamento Ágil de Projetos •  Unified Process (UP) – Processo Unificado •  Scrum – Processo de Desenvolvimento Intera%vo e Incremental de

Gerenciamento de Projetos •  Extreme Programming (XP) – Programação extrema •  Feature Driven Development (FDD) – Desenvolvimento Guiado por

Funcionalidades

Regras do Jogo Aulas aos sábados (serão repassados conteúdos) Dias das Provas – N1 -‐ Dias das Provas -‐ N2 – 1. Alunos com “moLvo” viagem em demasia, gravidez, doenças, não ficam isentos de fazerem provas, nem os trabalhos. 2. Faltas: Tolerância de 20 faltas / 21 faltas aluno (a) reprovado por falta. 3. JusLficaLvas de Faltas e trabalhos perdidos com o professor 4. Mais de 15 dias somente com atestado (secretaria) 5. Trabalhos em sala, interação e assiduidade – (perdeu? Resumo e explicação do assunto ao professor) 6. Provas marcadas (perdeu? -‐ 2ª chamada procurar a coordenação) 7. Dez Pontos de Assiduidade, ParLcipação nas aulas, conduta adequada do aluno (a) – entra e sai da sala, chegada atrasada em demasia. 8. Todo e qualquer trabalho deve ser entregue digitado. 9. Material de Estudo Livros na Biblioteca e material de apoio aposLla

Avaliação

Contato

[email protected]

[email protected]

8119-‐1133

1ª Parte Pressupostos Gerais sobre Gerenciamento de Projeto

Um Projeto é assim?

1.1 Atributos de um Projeto Tem que ter necessariamente um objeLvo bem definido – pode ser um resultado de um produto desejado. a) Um objeLvo de um projeto costuma ser definido em termos de escopo, cronograma e custo.

b) É conduzido por meio de uma série de tarefas independentes . Tarefas que devem ser conclusas em sequencias uma após a outra

Lançar no mercado, em dez meses, dentro de um orçamento de $ 500 mil, um novo forno de micro ondas que aqueça e grelhe alimentos e que atenda demais especificidades de desempenho predefinidas no projeto de produtos.

Uma casa só pode ser considerada uma casa se antes passar por uma sequencia lógica de tarefas que ao final darão a casa o senLdo de ser uma casa.

1. Premissas sobre Gerenciamento de Projetos É um esforço para se aLngir um objeLvo específico por meio de um conjunto único de tarefas inter-‐relacionadas e da uLlização eficaz de recursos.

c) Um projeto uLliza vários recursos para realizar as tarefas interdependentes citadas anteriormente. Podem ser considerados: Inputs de recursos transformados que são: materiais, informações e consumidores; ou ainda recursos de transformação que são: pessoal, equipamento e instalações.

Antes de lançar no mercado o novo forno de micro ondas ele precisou ser projetado, testado, avaliado... Para isso requereu: informações dos engenheiros, do pessoal no desenvolvimento de protóLpos para testes, requereu ainda uma estrutura de testes , máquinas, equipamentos, recursos financeiros...outros...

Um programador tem uma encomenda de um soNware empresarial, ele inicia os trabalhos e no meio do caminho a empresa decide pagar o programador pelo desenvolvido e pagar-‐lhe a multa do contrato firmado, pois não deseja mais o sistema. Agora a empresa comprará outro. Qual o moLvo do programador conLnuar com o projeto do soNware??? Nenhum, dessa forma o projeto será abortado.

d) Um projeto tem um tempo de vida finito. Uma caracterísLca de todo e qualquer projeto é que ele tem hora para iniciar e hora para terminar, mesmo que esse

momento de termino seja atrasado em muitos dias, meses ou anos. Um dia ele acaba, mesmo que não seja concluso. Será abortado.

e) Um projeto tem sempre um cliente (pessoa xsica ou jurídica), não existe projeto para ninguém, somente desenvolvemos projetos se for para alguém, ou grupo de pessoas. O cliente é a figura que financia o projeto, portanto as especificações devem atender as necessidades deste, senão...

O Material do curso de Gerenciamento de Projeto de Sistemas é para os alunos (as). Quando a FORD desenvolve um novo carro, pensa em comercializa-‐lo aos clientes, portanto com base nas necessidades de um carro por parte dos clientes a FORD cria o projeto de um novo carro e o põe na linha de produção, para depois ser comercializado.

f) É um esforço único de uma única vez, para clientes com desejos diferentes, e que é feito em tempo disLntos.

•  Projeto de uma sonda espacial; •  Projeto de soNwares customizados de Internet para

empresa; •  Projeto de construção de uma ponte, viaduto... •  Projeto de uma casa

É um projeto único? SIM ( ) NÃO ( )

g) Um projeto envolve um certo grau de incerteza. Por ser elaborado sem garanLa sobre: •  os recursos e o orçamento necessário e •  o tempo a de conclusão. Com base nas incertezas escopo, tempo e custos um projeto acaba sendo incerto.

Um experiente projeLsta com mais de 30 anos no oxcio terá um certo grau de certeza, mas esse grau nunca será 100%. Mesmo que este esteja trabalhando em um projeto similar servindo de parâmetro de um já realizado, e mesmo que esse projeto possa ter dado muitos aprendizados. O mesmo não pode dizer que tem uma certeza total do escopo, do tempo, orçamento, dos riscos. Haverá riscos. E os riscos devem ser gerenciados com base na experiência desse projeLsta.

1.1.1 Fatores que limitam o Sucesso do Projeto

É todo o processo que deve ser realizado afim de garanLr ao cliente que os itens, produtos ou serviços cumpram os critérios de aceitação acordados

É a quanLa que o cliente concordou em pagar por itens, produtos ou serviços acordados no projeto

Especifica as datas em que cada aLvidade deve começar e terminar. Prazo do Projeto

O objeLvo de qualquer projeto é concluir o escopo dentro do orçamento, dentro da data combinada afim de saLsfazer o cliente

1.2 Ciclo de Vida de um Projeto

1ª Fase IdenLficação das necessidades – problema, oportunidade e pode ou resultar de uma solicitação de proposta pelo cliente. Se houver solicitação a mesma se procede em um instrumento denominado: CHAMADA DE PROPOSTA – CP – o cliente solicita que consultores, projeLstas enviem uma proposta sobre como resolver a necessidade, e ou o problema.

2ª Fase – desenvolvimento da proposta. Essa fase resulta na entrega de uma proposta ao cliente. Dependendo do que tem que ser solucionado isso pode levar muito tempo. Ainda não é um contrato com o cliente.

3ª Fase – Implementação da solução da proposta. Fase de execução da proposta. Envolve o planejamento detalhado do projeto, e em seguida a implementação desse plano.

4ª Fase – Conclusão do projeto. É nessa fase que se efetuam as avaliações dos resultados alcançados.

1.3 O Processo de Gestão de Projetos

O processo de gestão de projetos significa planejar o trabalho e depois executar o plano. Um exemplo é uma equipe de desenvolvedores de sistemas para internet estarem debruçados sobre um projeto que revolucionará a metodologia de uma escola de idiomas, que pretende ser 100% virtual. Isso é planejar. Os alunos que usarão a ferramenta virtual desenvolvida julgarão eficaz ou não do ponto de vista do ensino e aprendizagem.

1.3 O Processo de Gestão de Projetos 1.3.1 Plano Base para o Processo de Gestão de Projetos 1º Passo – Definir claramente o objeLvo do projeto – essa definição deve ser acordada entre o cliente e os responsáveis pela elaboração e condução do projeto. 2º Passo – Dividir e subdividir o escopo do projeto em pacotes de trabalhos. Aqui trabalhamos com um ferramenta importan}ssima para essa fase chamada de EAP (estrutura analíLca de projetos) ou WBS, que é uma espécie de árvore hierárquica de elementos ou itens de trabalho realizados pela equipe durante o período em que o projeto esLver vigendo. 3º Passo – Definir aLvidades específicas que precisam ser conduzidas para cada pacote de trabalho a fim de aLngir o objeLvo do projeto. 4º Passo – Ilustre graficamente as aLvidades na forma de um diagrama de rede. Esse diagrama mostra a sequencia necessária e as interdependências das aLvidades para aLngir o objeLvo do projeto.

5º Passo – Fazer uma esLmaLva de tempo de quanto levará para completar cada aLvidade. É necessário determinar os recursos e como esses serão uLlizados em cada aLvidade. 6º Passo – Fazer uma esLmaLva de custos para cada aLvidade. O custo baseia-‐se nos Lpos e nas quanLdades de recursos necessários a cada aLvidade. 7º Passo – Calcular o tempo e o orçamento para determinar se o projeto pode ser concluído dentro do prazo necessário, com os recursos financeiros alocados e os demais recursos disponíveis.

1.4 Benexcio da Gestão de Projetos

O maior benexcio é ter clientes saLsfeitos. Com isso quem desenvolveu todo o projeto leva méritos e evidentemente é indicado para outros novos projetos.

Estudo de Caso E-‐commerce para um supermercado pequeno

2ª Parte Gestão de Projetos

Filosofia


Fundado em 1969 por cinco pessoas que entendiam o valor do networking, do comparLlhamento das informações dos processos e da discussão dos problemas comuns de

projetos. Após a primeira reunião oficial em outubro de 1969, no Georgia InsLtute of Technology em Atlanta, Geórgia, EUA, o grupo consLtuiu oficialmente a associação na

Pensilvânia, EUA.

Desde então, o PMI cresceu e se tornou o maior defensor mundial da profissão de gerenciamento de projetos. O PMI conta com mais de 300.000 associados – em mais de 160 países. Todos os principais setores estão representados, inclusive tecnologia da informação, defesa e aeroespacial, serviços financeiros, telecomunicações, engenharia e construção, agências governamentais, seguro, saúde e muitos outros.

A meta principal do PMI é avançar na práLca, na ciência e na profissão de gerenciamento de

projetos em todo o mundo, de uma maneira consciente e proaLva, para que as organizações em todos os lugares apoiem, valorizem e uLlizem o gerenciamento de

projetos – e então atribuam seus sucessos a ele.

Metodologia das Aulas

São documentadas as necessidades de negócio e os requisitos principais do produto serviço, ou sistema; apresenta a jusLficaLva do projeto; o entendimento das necessidades do cliente; descreve o produto, serviço ou sistema que será abordado nos requisitos. Em geral o termo de abertura responde e posteriormente documenta:

1.1 Termo de abertura do projeto

1.   Quais as necessidades, desejos e expectaLvas dos clientes patrocinadores e outras partes interessadas?

2.   Quais as necessidades de negócio, descrição de alto nível do projeto, além de requisitos do produto, serviços ou sistema que será abordado pelo projeto?

3.   Qual (is) o (s) objeLvo (os), que problema pretende ser resolvido?

4.   Qual a jusLficaLva para o projeto?

PROCESSOSDE INICIAÇÃO

Desenvolvero termo deabertura do

projeto

Identificar as partes

interessadas

1. PROCESSO DE INICIAÇÃO DO PROJETO

5.   Quais serão os marcos (regulatórios) do cronograma do projeto? 6.   Qual é o grau de influência dos stakeholders no projeto ? 7.   Quais premissas ou hipóteses que podem aumentar ou não o

risco do projeto: falta de recursos financeiro?, pessoal qualificado para as fases do projeto? que outras?

8.   Quais são as restrições organizacionais (empresa); do ambiente externo e interno? do sistema de informação? Dos processos?

PROCESSOSDE INICIAÇÃO

Desenvolvero termo deabertura do

projeto

Identificar as partes

interessadas

1. PROCESSO DE INICIAÇÃO DO PROJETO

Exercício Com base no CASE: E-‐commerce para um supermercado pequeno Pense em uma proposta para atender ao problema da empresa, e, seguida desenvolva um termo de abertura (texto) que tenha basicamente a resposta as oito questões básicas para elaboração de um termo de abertura.

O objeLvo de processo de planejamento integrado é garanLr a coesão e a coerência entre vários processos do planejamento do projeto.

2.1 Desenvolvimento do plano de gerenciamento de projeto

2. PROCESSO DE PLANEJAMENTO

O resultado deste processo é a geração do plano de projeto, que será uLlizado para guiar a execução e o controle do projeto, documentar as premissas de planejamento, a estratégia de desenvolvimento, formalizar o escopo e o cronograma, além de outras informações relevantes. O planejamento é construído através dos seguintes passos:

Ex.: os prazos são definidos em função dos recursos humanos , alocados para o projeto, e o nível de qualificação e as quanLdades destes recursos influenciarão o custo e a qualidade dos trabalhos.

Definição do Escopo

Desenvolvimento do plano de gerenciamento de projeto

a)  ObjeLvos do projeto; b)  Descrição do escopo do produto; c)  Requisitos do projeto; d)  Limites do projeto; e)  Entregas do projeto; f)  Critérios de aceitação do produto; g)  Restrição do projeto; h)  Premissas do projeto; i)  Organização da equipe e partes

interessadas; j)  Riscos iniciais definidos; k)  Marcos do cronograma; l)  Limitação de recursos financeiros; m)  EsLmaLvas de custos n)  Requisitos para o gerenciamento de

configuração o)  Requisitos de aprovação.

A declaração de escopo do projeto define, o que vai ser realizado pelo projeto e inclui as limitações do projeto. Em geral ela documenta:

Criação de uma EAP (estrutura analíLca de projetos) ou WBS (work breakdown structure). É uma espécie de check list que idenLfica todas as partes de um projeto e as tarefas associadas, ou seja subdivide o trabalho do projeto em partes menores que podem ser gerenciadas com maior facilidade. O que uma EAP apresenta como benexcio ao gerenciamento de projetos?


a)  Apresenta os produtos finais que serão entregues ao cliente, assim como os subprodutos intermediários;

b)  Fornece uma ilustração detalhada do escopo do projeto; c)  Dá origem ao cronograma e permite monitorar o progresso; d)  Mostra o detalhamento de custo de equipamento, mão de obra e materiais; e)  Auxilia na montagem da equipe e distribuição do trabalho; f)  Facilita a idenLficação de riscos.


Definir aLvidades

No nível mais baixo de uma EAP estão definidos os pacotes de trabalho que serão executados no projeto , e estes, por sua vez, são decompostos em aLvidades. Estas aLvidades darão origem ao cronograma do projeto, sendo que cada aLvidade deverá requerer uma entrada (input) e uma saída (output), onde o output de uma aLvidade deve ser o input da próxima aLvidade, ao nome disso chamamos de aLvidades dependentes com relacionamento lógico estre elas. Ex: o desenvolvimento de um soNware na aLvidade teste (beta) somente poderá ocorrer se muitas outras aLvidades anteriores Lverem sido executadas. A própria programação é uma delas.


Sequenciamento das aLvidades

Com a dependência de uma ou várias aLvidades dependentes com relacionamento lógico estre elas criamos o sequenciamento. A ferramenta mais adequada para se definir o relacionamento lógico entre as aLvidades ou o sequenciamento é o diagrama de REDE, ou conhecido como Diagrama de PERT (program evaluaLon and review technique) – Técnica de Avaliação e Análise de Programas.

Exemplo: Diagrama de Rede


EsLmaLva dos recursos das aLvidades Após a elaboração do diagrama, o próximo passo é atribuir, para cada pacote de trabalho, a quanLdade necessária de recursos (pessoas e materiais), seus custos e prazos. EsLmaLva de Duração das aLvidades Existem várias maneiras de fazer esLmaLvas de prazos, um exemplo é buscar os projetos anteriores e verificar seus históricos de tempo para aLvidades similares. Mas quando não se tem tais projetos, a recomendação é ouvir as pessoas que estarão na operação das referidas aLvidades.


Cont. EsLmaLva de Duração das aLvidades As esLmaLvas de tempo devem ser realistas e não oLmistas, caso contrário as pessoas poderão ter expectaLvas erradas da realidade do projeto. Quando há muita incerteza na elaboração da esLmaLva, pode-‐se uLlizar o PERT (ferramenta já demonstrada anteriormente) Essa técnica usa peso médio ponderado para calcular a duração das aLvidades, ou seja, a esLmaLva considerada é igual a formula abaixo:

PRAZO OTIMISTA + PRAZO PESSIMISTA + (PRAZO PROVÁVEL x 4)

6


Desenvolvimento do Cronograma O cronograma do projeto tem como base as aLvidades e o tempo que cada uma delas leva para ser concluída, e também seus relacionamentos lógicos (sequenciamento). No cronograma quando se insere as aLvidades o mesmo vai definindo quais daquelas serão mais críLcas no momento de conclusão. A essas aLvidades que somam todo o tempo do projeto chamamos de aLvidades críLcas, que são descritas em um cronograma de Gan� simples, no próprio sistema de gerenciamento de projetos da microsoN o MS-‐Project.

Como fazer um EAP? Por onde começo?

O que tenho que fazer?

Modelo Genérico de EAP para Desenvolvimento de SoNware

Modelo de EAP com detalhamento de níveis, dos executores (RH) e das fases

Modelo de EAP desenvolvida no MS-‐Project 2003 – Projeto de Implantação de uma Clínica de Fisioterapia e Reabilitação em Porto Velho – CIA do MOVIMENTO

Dicionário EAP

Desenvolvimento do Cronograma O dicionário da EAP é um documento gerado pelo processo criação da EAP que a suporta. Fornece descrições mais detalhadas dos componentes da EAP, inclusive dos pacotes de trabalho e contas de controle. Em um dicionário da EAP são exigidas duas informações 1)  A Descrição da aLvidade 2)  Os critérios de aceite da mesma

Exemplo: Dicionário EAP

Desenvolvimento do plano de gerenciamento de projeto EsLmaLva dos custos O planejamento do custos tem por objeLvo a elaboração do orçamento do projeto, definindo-‐se os recursos que serão uLlizados (pessoas, equipamentos e materiais de consumo), suas respecLvas quanLdades e as datas em que serão necessários.

A EAP é a principal fonte para o planejamento dos custos, já que ela idenLfica os resultados do projeto.

No início do projeto, geralmente o planejamento é composto de uma esLmaLva preliminar que apresenta apenas ordem de grandeza, que pode ter uma precisão entre – 25% e + 75%. Á medida em que o projeto evolui, esLmaLvas mais precisas são elaboradas com precisão entre -‐10% e + 25%. A esLmaLva definiLva do planejamento dos custos geralmente tem uma precisão entre -‐5% e + 10%, uma vez que há mais conhecimento sobre o trabalho.

Desenvolvimento do plano de gerenciamento de projeto EsLmaLva dos custos Métodos de custos adotados em projetos mais conhecidos são os TOP-‐DOWN e BOTTOM-‐UP.

TOP-‐DOWN – é uLlizada nas fases iniciais do projeto, quando as informações disponíveis são bastante limitadas. Neste método é elaborado uma única esLmaLva para o projeto inteiro, sendo, depois, este valor rateado entre os elementos na EAP.

A esLmaLva pode ser realizada consultando especialistas, o próprio histórico de projetos similares O método BOTTOM-‐UP é usado quando há necessidade de precisão nos valores. As esLmaLvas de custos são definidas para os elementos dos níveis mais baixos da EAP.

Para obter o custo de um item intermediário, de um nível mais alto da EAP, basta somar os custos dos elementos que estão abaixo dele.


EsLmaLva dos custos Quando há incerteza nos cálculos dos custos, pode ser uLlizada a técnica probabilísLca do PERT, também usada na esLmaLva de tempo. Desta forma, a esLmaLva de custo é igual. A vantagem do método BOTTOM-‐UP é a maior precisão, enquanto que a principal desvantagem é o tempo e o esforço necessário no processo de cálculo dos custos.

CUSTO OTIMISTA + CUSTO PESSIMISTA + (CUSTO PROVÁVEL x 4)

6


Análise dos Custos Em projetos, o poder de influência sobre os custos é maior no início, quando eles ainda não são totalmente conhecidos. O gerenciamento dos custos tem um papel importante no planejamento e na definição dos pacotes de trabalhos do projeto, pois ele fornece dados para o sistema de informações que as empresas uLlizam para a tomada de decisão. Na elaboração do orçamento, precisamos ter conhecimento dos custos que irão incorrer no projeto para que o gestor tenha consciência do o gestor efeLvamente quer para o projeto.


Análise dos Custos Armadilhas a serem evitadas para um bom gerenciamento dos custos 1)  Má interpretação da declaração de

trabalho do projeto, quando ele é resultado de um contrato;

2)  Escopo com omissões ou mal definido; 3)  Cronograma pobremente definido ou

muito oLmista; 4)  EAP pouco detalhada; 5)  Previsão de recursos com perfil

inadequado para as tarefas; 6)  Falha na quanLficação de riscos; 7)  Falha no entendimento e contabilização

dos diversos Lpos de custos; 8)  Escolha errada das diferentes técnicas

de esLmaLvas de custos.


Custos Diretos São idenLficados e quanLficados, a parLr dos recursos necessários. São aqueles diretamente atribuídos ao trabalho do projeto. Exemplo de custos diretos: a)  Mão de obra (mensurados através das

horas de trabalho); b)  Materiais (alocados conforme descrição

das necessidades); c)  Equipamentos (descrição conforme

necessidade); d)  Serviços terceirizados (alguns ligados a

produção do projeto); e)  Insumos a produção (quando

necessários para o processamento das aLvidades do projeto)


Custos Indiretos São despesas em gerais e gastos incorridos pela empresa em benexcio de mais de um projeto, normalmente são custos relaLvos a manutenção do negócio. Não são facilmente idenLficados, pois se relacionam com as aLvidades de funcionamento da empresa como um todo e poderão ser rateados com outros custos de fácil mensuração. Esses custos são analisados em quatro grupos de análise a)  Custos administraLvos => relacionados as aLvidades da administração: salários dos

diretores, do pessoal de assessoramento e administraLvo, materiais de escritório e outros (das aLvidades meio da empresas)

b)  Custos comerciais => incorridos na comercialização dos produtos da organização: markeLng, promoção do produtos/serviços/sistema (aLvidades relacionadas a mídia promocional e outras relacionadas as formas de venda)

c)  Custos tributários => decorrem de disposições legais: tributos, taxas, impostos, emolumentos e tarifas.

d)  Custos financeiros => são aqueles nos quais se referem ao custos do dinheiro: juros de emprésLmos necessários para financiar o projeto


Custos Fixos São aqueles que não variam com a quanLdade de aLvidade do projeto, ou para uma dada faixa de volume de projetos, como por exemplo: instalações, aluguéis etc. Quanto mais projeto, mais pessoas estarão trabalhando e precisarão de mais espaço, logo será necessário aumentar o número de salas, computadores...


Custos Variáveis Se modificam de forma proporcional e direta, em função da dimensão do trabalho do projeto ou da quanLdade dos produtos produzidos como, por exemplo: materiais e suprimentos uLlizados no projeto


Custos Totais São os consLtuídos pela somatória dos custos diretos mais os indiretos; dos fixos e variáveis.


Orçamentação O orçamento agrega os custos esLmados em uma EAP para que assim possa-‐se estabelecer uma linha de base dos custos totais do projeto. O desempenho do projeto é avaliado com base no dinheiro que entra e que sai durante o seu ciclo de vida. No orçamento além dos custos normais previstos na EAP, pode-‐se esLmar um percentual de aumento referentes as conLngências do projeto.


Orçamentação


Planejamento da Qualidade Esse processo ocorre em paralelo com outros processos de planejamento. Busca definir os padrões de qualidade que precisam ser seguidos. O resultado do planejamento da qualidade é um plano que descreve como a qualidade do projeto será garanLda, assim como as aLvidades que a equipe do projeto terá que executar para garanLr este objeLvo. No planejamento da qualidade examinam-‐se as caracterísLcas do produto comparando-‐os às necessidades explícitas e implícitas dos stakeholders (interessados) no projetos.


Planejamento da Qualidade A qualidade de um produto se aplica tanto aos elementos técnicos e funcionais como a documentação. A solução deve agradar ao cliente, ser de fácil administração, robusta, confiável e estável. A documentação deve ser completa, clara, de fácil consulta e seguir os padrões impostos pelo cliente. No âmbito do próprio projeto a qualidade está associada ao cumprimento das instruções de trabalho que regem o projeto: comunicação, cumprimento das metas, prazos e orçamento de cada pacote de trabalho, gerenciamento dos riscos e tudo o que mais puder ser gerenciado e verificado se vai atender as necessidades do clientes.


Planejamento da Qualidade Princípios da Qualidade: 1) Fazer o trabalho certo na primeira tentaLva, economizando recursos materiais (dinheiro) e tempo; 2) A qualidade é um processo prevenLvo; 3) Cumprir as exigências e especificações do escopo do projeto, através da sua EAP; 4) Produzir produtos e serviços que atendam às necessidades do cliente; 5) Entregar produtos cujas funcionalidades foram devidamente testadas. Não deve haver falhas no produto entregue!

6) A qualidade é responsabilidade de todos os membros da equipe;

7) A qualidade é um processo de aprimoramento con}nuo.


Ferramentas da Qualidade para Gestão de Projetos: 1)  CICLO PDCA (FILOSOFIA DE GESTÃO) 2)  FLUXOGRAMA DE PROCESSOS 3)  FOLHA DE VERIFICAÇÃO 4)  CARTA DE TENDÊNCIA 5)  CHECK LIST DE ADERÊNCIA 6)  DIAGRAMA DE ISHIKAWA (CAUSA E

EFEITO DOS PROBLEMAS EM GESTÃO DE PROJETOS)

7)  MATRIZ DE GUT (GRAVIDADE, URGÊNCIA E TENDÊNCIA)

8)  HISTOGRAMAS 9)  DIAGRAMA DE PARETO


PLANEJAR (P) -‐ definir metas, horizontes, métodos e técnicas. Pode ser um planejamento

estratégico, um plano de ação, um conjunto de padrões ou cronograma.

EXECUTAR (D) -‐ executar as tarefas exatamente como previsto na etapa de planejamento

e coletar dados para verificação do processo. Pode ser um programa de treinamento e

educação seguido de ações operacionais concretas, por processo. Nesta etapa são

essenciais a educação e o treinamento.

VERIFICAR (C) – a parLr dos dados coletados na execução, comparar as metas definidas

com os resultados obLdos.

CORRIGIR (A) -‐ eliminar as causas idenLficadas como geradoras dos desvios (diferenças

entre meta e resultado), para que mesmo moLvo, esses desvios, não voltem a ocorrer. A

ação correLva pode ocorrer no planejar, no executar, no verificar e no próprio corrigir


Planejamento As etapas a serem seguidas no planejamento para a qualidade são: ·∙ 1) IdenLficação do produto ou do serviço •  IdenLfique o resultado produzido, não a aLvidade. •  IdenLfique o resultado específico, não o genérico. •  Diferencie os resultados intermediários dos resultados finais. •  IdenLfique os resultados de acordo com o seu nível de responsabilidade. 2) IdenLficação do cliente •  IdenLfique o grupo que é o próximo a parLcipar no processo de trabalho. •  IdenLfique a pessoa, dentro do grupo. •  Verifique se há clientes indiretos. •  Verifique a seqüência do processo até chegar ao cliente final. 3) IdenLficação dos requisitos do cliente •  ConscienLze-‐se de que cada cliente pode ter necessidades diferentes. •  IdenLfique os requisitos racionais do cliente. •  IdenLfique os requisitos afeLvos do cliente. 4) Transformação dos requisitos do cliente em especificações •  Verifique se as caracterísLcas desejadas podem ser medidas. •  Analise os requisitos para verificar se não existem contradições. •  Verifique se todos os requisitos têm o mesmo peso. •  Analise se os requisitos do cliente são viáveis. •  Verifique o que pode ser negociado.


Organização Na organização para a qualidade as etapas a serem seguidas são:

1) Definição dos elementos do processo

•  IdenLfique os conhecimentos e as habilidades necessárias ao desenvolvimento do

processo.

•  Procure conhecer a natureza dos materiais e das informações que serão uLlizados.

•  Faça um levantamento dos recursos e das instalações possíveis.

•  Oriente-‐se quanto aos métodos e aos procedimentos adequados.

•  Estabeleça padrões de desempenho.

2) Estabelecimento de medições necessárias IdenLfique:

•  O que medir.

•  Como medir.

•  Quando medir.


3) Determinação da Capacidade do Processo

•  Verifique se o processo atende aos requisitos do cliente, a um custo de não-‐

conformidade zero.

•  Assegure-‐se de que o processo escolhido seja efeLvamente capaz de produzir

o resultado desejado.

•  Avalie se as variações do processo permitem atender plenamente aos

requisitos do cliente.


Controle O controle da qualidade se verifica quando são executados os seguintes passos:

1) Avaliação dos Resultados do Processo

•  Compare o que foi efeLvamente obLdo com as especificações acordadas com o cliente.

•  Decida, após esta comparação, as ações que devem ser executadas a seguir.

2) Reciclagem do Processo

•  Procure idenLficar as oportunidades de melhoria, se nenhum problema for detectado.

•  Adote a metodologia de análise e solução de problemas, se a avaliação indicar a

existência de um resultado indesejado do processo.

•  Recicle o processo.


Estudando as Ferramentas Por que uLlizar

•  A uLlização de metodologias de trabalho, e a aplicação de ferramentas que

sejam do conhecimento de todos na organização, dentro da mesma filosofia,

cria uma nova “linguagem administraLva”, inclusive gráfica, que permite uma

maior rapidez e transparência nas comunicações internas e a consequente

agilização na tomada de decisões.

•  As ferramentas da qualidade não são uma invenção nova, algumas delas já

existem desde a II Guerra Mundial, e combinadas a outras mais recentes

formam o atual conjunto de que se dispõe para o desenvolvimento de ações de

melhoria. É comum classificá-‐las em ferramentas esta}sLcas e não esta}sLcas.


Ferramentas não Esta}sLcas Fluxograma •  É a representação esquemáLca, da sequência (setas) das etapas (caixas) de um

processo, e tem por objeLvo ajudar-‐nos a perceber sua lógica dos fluxos e roLnas.

•  O fluxograma serve para compreender e melhorar o processo de trabalho, criar um

procedimento padrão de operação e mostrar como o trabalho deverá ser feito.

•  É uLlizado também, como ferramenta de comunicação, de compreensão, aprendizado

e auxílio à memória; possibilita idenLficar instruções incompletas, "loops" perigosos e

serve como roteiro de controle e padronização. É muito úLl na idenLficação e

resolução de problemas e na operacionalização, no controle e na melhoria de um

processo.

•  Na construção de um fluxograma são uLlizados símbolos variados, e os mais comuns

são os apresentados a seguir:


Indica o início e o fim do fluxo, devendo essa indicação ser escrita dentro do símbolo.

Fluxograma-‐ Símbolos mais usuais

Indica a execução de uma ação no fluxo, devendo essa ação ser descrita sinteLcamente dentro do símbolo

Indica uma pergunta, a qual deverá estar conLda no símbolo

Indica o senLdo do fluxo

Indica a sequência do fluxo, devendo ser numerado para que não se perca a ordem de execução.


Exemplo de Fluxograma

Processo ??? Operações ???


Folha de Verificação

•  É a ferramenta uLlizada para padronizar e verificar resultados de trabalho ou para facilitar e

organizar o processo de coleta e registro de dados.

•  As Folhas de Verificação para coleta e organização de dados são também chamadas de Folhas de

Dados. São formulários, nos quais os itens a serem observados são previamente impressos,

permiLndo a oLmização da análise dos dados obLdos.

Na preparação de uma Folha de Verificação devem ser incluídos, sempre que possível, os seguintes

itens:

•  ObjeLvo da verificação (por que -‐ "why");

•  Os itens a serem verificados (o que -‐ "what");

•  Os métodos de verificação (como -‐ "how");

•  A data e a hora das verificações (quando -‐ "when");

•  O nome da pessoa que faz a verificação (quem -‐ "who");

•  Os locais e processos das verificações (onde -‐ "where");

•  Os resultados das verificações;

•  A sequência das verificações.


Além disso, é necessário:

•  Definir o período para a coleta de dados;

•  Elaborar um formulário simples e fácil de ser preenchido;

•  Verificar se os dados podem ser colhidos consistente e oportunamente.

Exemplo de uma Folha de Verificação

Carta de Tendência

São representações gráficas de dados coletados, em um determinado período, para

identificar tendências ou outros padrões que ocorrem ao longo deste período.


Exemplo de Carta de Tendência

Checklist de Aderência

É um formulário, previamente elaborado, para coleta de opiniões sobre o quanto

pessoas ou organizações conhecem, aceitam ou praLcam ações, princípios ou

comportamentos que estão sendo avaliados.

Minutos que se leva para começar a trabalhar na seção X


CHECKLIST DE ADERÊNCIA AOS PRINCÍPIOS DA QUALIDADE

5 4 3 2 1 Aderente Não Aderente

Bastante

Extremamente

Levemente

Bastante

Extremamente

Levemente

0

Exemplo de Tabela de Chek List de Aderência


5. Diagrama de causa e efeito

•  É uma ferramenta uLlizada para apresentar a relação existente entre o resultado de um

processo (efeito) e os fatores (causas), que possam afetar este resultado; estudar

processos e situações, e como ferramenta de planejamento.

•  É também conhecido como diagrama de espinha de peixe ou diagrama de Ishikawa.

Desenvolvido no Japão, em 1943, por Kooru Ishikawa, permite, ainda, representar a

relação entre problema e todas as possibilidades de causas que podem implicar neste

efeito.

•  Para facilitar a construção do diagrama, Ishikawa idealizou quatro categorias de causas

conhecidas como 4M. Outras categorias foram propostas e nada impede que cada

pessoa proponha sua próprias categorias, não esquecendo, todavia, que a simplicidade

é o segredo para o bom funcionamento desta ferramenta.


As categorias mais comuns, para agrupamento das causas podem ser:

•  4M: Mão-‐de-‐obra, Máquina, Método do Processo ou da Medida e Materiais.

•  5M: Mão-‐de-‐obra, Máquina, Método, Materiais e Manager (Gerenciamento).

•  6M: Mão-‐de-‐obra, Máquina, Método, Materiais Manager e Meio Ambiente.

•  7M: Mão-‐de-‐obra, Máquina, Método, Materiais, Manager, Meio Ambiente e Money

(Dinheiro).

Processo de elaboração de um Diagrama de Causa e Efeito 1. Escreva o problema a ser analisado em um retângulo à direita de uma folha de cartolina, flip-‐chart, quadro branco, quadro para giz, etc.

Reuniões Não ProduLvas O Problema


2. Trace uma reta, da esquerda para a direita, acrescentando uma seta no ponto em que a reta encontra o retângulo.

Reuniões Não ProduLvas

3. Relacione as causas básicas dentro de retângulos e ligue cada um deles ao eixo horizontal do diagrama.

Reuniões Não ProduLvas

Local Mão de Obra

Gerência Método

Esses fatores são gerais e seu número varia Lpicamente de 4 a 6 categorias


4. Relacione, como espinhas médias, as causas secundárias, terciárias e quaternárias. Para cada causa primária (dentro dos retângulos) 5. IdenLfique subcausas (secundária, terciária e quaternária) que as afetam. Exemplo de Diagrama de Ishigawa


Matriz de GUT

Gravidade (impacto do problema sobre coisas, pessoas, resultados, processos ou

organizações e efeitos que surgirão a longo prazo, caso o problema não seja resolvido);

• Urgência (relação com o tempo disponível ou necessário para resolver o problema)

• Tendência (potencial de crescimento do problema, avaliação da tendência de

crescimento, redução ou desaparecimento do problema).



Planejamento de aquisições Recursos Humanos Envolve a descrição, o recrutamento e a seleção de profissionais para suprimento dos cargos, funções, responsabilidade e competências no projeto. Para definir responsabilidades aos profissionais no projeto se desenvolve uma simples matriz.


Planejamento de aquisições Recursos Materiais Envolve a descrição dos inputs de recursos de materiais necessários a todas as etapas do projetos.

Quando se desdobra as aLvidades na EAP, e de define as responsabilidades aos gerentes cada um terá que planejar suas necessidades de materiais, que como consequência será lançada no orçamento do projeto.

Se a qualidade não for a máxima em um projeto os gerentes podem por descuido esquecer itens importantes em um projeto, o que ocasionará aumento dos custos e insaLsfação do cliente.

+ + + +


Planejamento das Comunicações No planejamento das comunicações define-‐se que informações precisarão ser geradas, para quem e como serão distribuídas. O ObjeLvo é perguntar: Quem precisa da informação? De que informações precisam? Quando e como vão obter as informações? Em projetos pequenos não há necessidade de se formalizar o plano de comunicação, pois nestes casos a quanLdade de pessoas envolvidas geralmente é pequena. A seguir inserimos um quadro como exemplo de como o plano de comunicação poderia ser registrado. Todos os documentos em registros do projeto indicados no quadro devem ser manLdos em local acessível para todos os parLcipantes.


Planejamento das Comunicações


Planejamento das Comunicações O Plano de Comunicação deve considerar as seguintes informações:

•  Detalhamento das informações a serem coletadas e os respecLvos métodos de armazenamento;

•  Definição de um estrutura de distribuição das informações, indicando os desLnatários e os métodos de distribuição

•  Descrição das informações, incluindo seu formato, conteúdo e o nível de detalhamento

•  Cronograma das comunicações

•  Métodos de acesso às informações, depois de armazenadas, e esquemas de controle de acessos

•  Método para revisão do plano de comunicação

A palavra RISCO é derivada do Italiano anLgo RISICARE, que quer dizer OUSAR, e pode ser originada também do laLm RISCU, RISICU que significa INCERTEZA. Risco deve ser entendido como um: (1) UM CONJUNTO DE INCERTEZAS ENCONTRADAS QUANDO UMA PESSOA OUSA FAZER ALGUM EMPREENDIMENTO QUALQUER. (2) PMI-‐ É UM EVENTO OU CONDIÇÃO INCERTA QUE, SE OCORRER, PROVOCARÁ UM EFEITO POSITIVO OU NEGATIVO NOS OBJETIVOS DE UM PROJETO . (3) PMI-‐ GESTÃO DE RISCOS É O PROCESSO DE IDENTIFICAÇÃO, ANÁLISE, DESENVOLVIMENTO DE RESPOSTAS E MONITORAMENTO DOS RISCOS EM PROJETOS, COM OBJETIVO DE DIMINUIR A PROBABILIDADE E O IMPACTO DE EVENTOS NEGATIVOS E DE AUMENTAR A PROBABILIDADE E O IMPACTO DE EVENTOS POSITIVOS Sempre que se planeja algo se lida com inúmeras variáveis de incerteza que são os possíveis riscos inerentes a qualquer Lpo de empreendimento.


Os riscos estão ligados a apostas que uma empresa ou uma pessoa pode pode fazer para crescer , desenvolver, obter maiores ganhos, melhores remunerações.

Ex: a Bolsa de valores é um Lpo invesLmento onde muitas empresas buscam capitalizar de grandes invesLdores recursos financeiros para financiar seus invesLmentos. Os invesLdores correm riscos elevados, pois a remuneração futura é totalmente incerta, não se sabe com 100% de certeza se aquela empresa que trocou papéis por recursos financeiros irá dar o retorno necessário e seguro aos seus invesLdores. Só se saberá se um determinado invesLmento terá sucesso se o empreendedor TENTAR, nesse caso os riscos são inerentes as inconstâncias existentes em torno de variáveis que cercam uma empresa, um empreendimento, etc…


Sem Informação

TOTAL INCERTEZA

Total Informação

TOTAL CERTEZA

Informação Parcial

INCERTEZA GERAL

INCERTEZA ESPECÍFICA

ESPECTRO DA GESTÃO DE RISCOS DO PROJETOS

Espectro da Gestão de Riscos

O Espectro da Gestão de Projetos não cobre a total certeza, nem a total incerteza, cobre, no entanto, um espectro de incerteza previsível que contempla a maior parte do que pode ocorrer com projetos no que se refere aos riscos que ele esta sujeito.


Gerenciar os riscos de um projeto envolve tomar decisões em ambiente incerto, complexo, de alta turbulência.

Pergunto: 1) DO QUE VOCÊ TEM CERTEZA QUE IRÁ ACONTECER NO FUTURO? 2) O QUE PODE DAR ERRADO NO PROJETO? Os riscos apresentam obrigatoriamente três componentes: 1 – Evento em si, onde deve ser idenLficada a causa raiz (a fonte) do risco, bem como seu efeito (consequência); 2 – A probabilidade esta geralmente associada a causa, ou seja uma quanLdade relaLva do risco acontecer; 3-‐ O impacto que um risco idenLficado poderá causar ao projeto, esta esta associado ao efeito.


Ex: sobre os três componentes dos riscos Ao adquirir um veículo uma pessoa decide colocar seu carro no seguro. Ao assegurar o veículo, a pessoa não esta atacando a causa do risco, pois a probabilidade de acidentes e roubos conLnuam as mesmas de antes de se fazer o seguro. A pessoa esta atacando o efeito (impacto), pois, caso ocorra algum sinistro ou roubo, quem paga é a seguradora, pois transfere o risco para a própria.


Qualquer projeto que se faça é gerenciado por pessoas e cada pessoa reage de maneira diferente a cada situação nova que aparece em um projeto. Os seres humanos tem diferentes graus de atração ou exposição a riscos – tem diferentes crenças, experiências , padrões de comportamento ,etc. Duas são as situação disLntas que marcam a reação das pessoas aos riscos: aquelas avessas ao risco (medo de perder), e aquelas pessoas que tomam decisões de riscos (sabem do que podem perder, mas mesmo assim ganhar mais os fascina a apostar em um Lpo de projeto inteiramente arriscado)


Uma das principais preocupações do gerente de projeto e de sua equipe em relação aos riscos deve acontecer logo no início do projeto e se refere ao planejamento do gerenciamento de riscos. Os riscos associados a um projeto em geral dizem respeito aos objeLvos do próprio projeto que por sua vez intefere no: TEMPO, no CUSTO, no ESCOPO, na QUALIDADE ou através da combinação destes.



Iniciando a Gestão de Riscos

O planejamento dos riscos somente deverá ser iniciado após termos planejado o projeto: seu objeLvo, desenvolvida a EAP, planejado as entregas (fases), a qualidade, o cronograma, a esLmaLva de custos

As variáveis de riscos que podem afetar um projeto são originadas de: •  FATORES AMBIENTAIS disponibilidade econômicas do ambiente; •  FATORES DE LIMITAÇÃO INTERNA relacionada a pessoal e outros inputs necessários para tornar viável a conclusão do projeto principalmente a falta de recursos financeiros que é o centro de todo e qualquer suprimento de materiais e demais insumos necessário a viabilidade de um projeto. •  DECLARAÇÃO DE UM ESCOPO que possa balizar as ações asserLvas do projeto. •  PLANO DE GERENCIAMENTO DE RISCOS – possibilidade de pensar antecipadamente em conLgências e se previnir também de forma antecipada a elas.

IdenLficação dos Riscos


Os riscos podem ou não afetar o projeto negaLvamente. Entretanto é necessário idenLficar todos os eventos de risco e suas respecLvas consequências.

Orçamento/fundos de reserva

Cronogramas

Mudanças no Escopo ou nos requisitos

Plano do Projeto

Processo de Gerenciamento do Projeto

Problemas Técnicos

Problemas Pessoais

Hardwares

Contratos

Problemas polí?cos

Riscos Empresariais

Possibilidade de Riscos ocorrerem em projetos



ConLnuação Riscos Legais

Riscos Ambientais

A lista de possibilidade associadas aos riscos de projetos está longe de ser exausLva. Cabe ao gestor em conjunto com a equipe do projeto analisar bem os possíveis riscos oriundos de um projeto específicos. Nesse caso o objeLvo da idenLficação de riscos é gerar uma lista de possíveis fatos que por ventura podem ocasionar problemas na conclusão do projeto (TEMPO), no orçamento (CUSTO) e modificações no ESCOPO (qualidade)



Outra forma de catalogar os possíveis riscos de um Projeto é uLlizar a metodologia da Estrutura AnáliLca de Riscos (EAR)

PROJETO

TÉCNICO EXTERNO ORGANIZACIONAL GESTÃO DE PROJETO

REQUISITOS

TECNOLOGIA

COMPLEXIDA E INTERFACES

DESEMPENHO E CONFIABILIDADE

QUALIDADE

SUBCONTRATOS E FORNECEDORES

ASPECTOS LEGAIS

MERCADO

CONSUMIDOR

MEIO AMBIENTE

DEPENDÊNCIA DO PROJETO

RECURSOS

FUNDOS

PRIORIZAÇÃO

ESTIMATIVAS

PLANEJAMENTO

CONTROLE

COMUNICAÇÃO

EAR



Instrumentos para coletar informações quanto a idenLficação dos riscos de um projeto. 1-‐ Brainstorming e Brainwri�ng Técnica conhecida por muitos para coletar informações para resolução de problemas nas empresas Regras para o brainstorming: 1)  Não ao não – não se deve quesLonar ou rebater qualquer idéia que tenha sido

apresentada por um membro da equipe de projeto. 2)  Não existe outras regra. Conforme as idéias vão sendo apresentadas, uma pessoa vai documentando (fazendo

anotações); ao final da sessão temos uma lista de riscos idenLficados para o projeto.



Instrumentos para coletar informações quanto a idenLficação dos riscos de um projeto. 2-‐ Técnica Delphi Funciona como se fosse um brainstorming remoto e anônimo, e apresenta o seguinte processo: a)  Designa-‐se um facilitador e escolhem-‐se os parLcipantes, que serão os mesmo

stakeholders abordados na técnica de brainstorming. Apenas o facilitador terá conhecimento dos parLcipantes.

b)  O facilitador distribui as informações sobre o projeto e pede aos parLcipantes que gerem uma lista de riscos, individual e anonimamente, e que lhe seja enviada.

c)  O facilitador consolida as diversas listas em uma única e redistribui aos parLcipantes para que cada um revise ou complemente

d)  Os parLcipantes devolvem a lista de riscos para o facilitador consolidar novamente.



ConLnuação 4-‐ Diagrama de Causa e Efeito (espinha de peixe) – Ishikawa Essa ferramenta tem como objeLvo mostrar as causas e os efeitos de um risco em um determinado projeto. As causas são agrupadas por categorias As etapas para elaboração do diagrama de causa/efeito 1 -‐ discussão do assunto a ser analisado pelo grupo, contemplando seu processo, como ocorre, onde ocorre, áreas envolvidas e escopo. 2 – descrição do efeito (problema) no lado direito do diagrama (cabeça) 3 – levantamento das possíveis causas e seu agrupamento por categoria no diagrama 4 – análise do diagrama elaborado e coleta de dados para determinar a frequência de ocorrência das difererentes causas.



Processo de IdenLficação de Riscos

(1) (Projetos anteriores)

(1) EAR

BRAINSTORMING

BRAINWRITTING

TÉCNICA DELPHI

ANÁLISE DE SWOT

(2) DEFINIR FERRAMENTAS

(3) DESCRIÇÃO DOS RISCOS (4) CATEGORIA

(5) LISTA DE RISCOS

DIAGRAMA DE ISHIKAWA


O Processo da Análise de Riscos Uma vez que a equipe de projetos tenha idenLficado os riscos através dos instrumentais desenvolvidos, a próxima etapa é definiar a análise desses riscos que podem ser analisados de maneira qualitaLva e quanLtaLva . Como observamos no início de nosso curso os componentes dos riscos são: EVENTO DE RISCO (CAUSA E EFEITO); PROBABILIDADE e IMPACTO. Todo risco tem uma probabilidade associada que não é zero (zero é certeza da não-‐ ocorrência) Nem 100% (certeza da ocorrência de um fato) e caso ocorra ocorrerá um IMPACTO. Existem duas maneiras de se dar peso ao risco. Primeiro por meio da qualificação ou da quanLficação.


ConLnuação Sem o peso de cada riscos o gestor de um projeto não tem como decidir adequadamente sobre que Lpo de reação seria válido para esse risco ou pior: quanto os stakeholders do projetos estariam dispostos a pagar por esse risco. ANÁLISE QUALITATIVA Visa detectar o impacto dos riscos idenLficados sobre os objeLvos do projeto e sua probabilidade de ocorrência. Também classifica os riscos por prioridade, de acordo com os efeitos sobre os objeLvos do projeto.


ConLnuação -‐ ANÁLISE QUALITATIVA FERRAMENTAS E TÉCNICAS PARA ANÁLISE QUALITATIVA DOS RISCOS

Avaliação de Probabilidades e Impacto do Risco Avalia a probabilidade de os eventos de risco idenLficados ocorrerem e calcula seu efeito sobre os objeLvos do projeto, incluindo: TEMPO, ESCOPO, QUALIDADE e CUSTO. PROBABILIDADE Uma probabilidade é uma chance de um evento ocorrer. Ao jogar uma moeda para cima a probabilidade dessa cair com a face CARA OU COROA é de 50% para cada lado.

Pode ser dixcil avaliar a probabilidade de um risco, o que costuma ser feito por meio da opinião especializada. Isso significa que procuramos adivinhar a probabilidade de ocorrência de determinados eventos de riscos. Nossos palpites são baseados em experiências anteriores em projetos ou eventos de riscos similares, mas não há evento igual a outro.


ConLnuação

IMPACTO O Impacto é a quanLdade de danos (ou ganhos) que um evento de risco representa para um projeto. A escala de impacto de riscos pode ser uma escala relaLva na qual se atribuem valores como ALTO, MÉDIO OU BAIXO. Ou valores numéricos atribuídos ao impacto dos riscos e expressos como números entre: 0,0 e 1,0.

OBJETIVOS BAIXO/BAIXO BAIXO MÉDIO ALTO ALTO/ALTO

CUSTO

0,05 Nenhum impacto significativo

0,20 Aumento inferior a 6%

0,40 Aumento de 7 a 12%

0,60 Aumento de 13 a 18%

0,80 Aumento superior a 18%

TEMPO

Nenhum impacto significativo

Aumento inferior a 6%

Aumento de 7 a 12% Aumento de 13 a 18%

Aumento superior a 18%

QUALIDADE

Nenhum impacto significativo

Poucos componentes afetados

Impacto significativo, exigindo aprovação do cliente para continuar

Qualidade inaceitável

Produto inutilizável


ConLnuação

Uma das formas das organizações definirem os critérios de aceitação dos riscos, com base nos parâmetros de probalidades e impacto, é por meio de uma grade de tolerância a riscos.

Baixa probabilidade de impacto

Análise__ Riscos Projetados no quadrante 1 – seriam aceitáveis para a organização Riscos no quadrante 2 e 4 precisam de propostas de estratégias de prevenção. Riscos no quadrante 3 seriam considerados inaceitáveis

Alta probabilidade de impacto


ConLnuação

A tabela abaixo apresenta uma visão comparaLva entre os riscos, permiLndo que seja visualizado um peso para cada risco e que se comparem os riscos entre si.

Identificação de Riscos Avaliação qualitativa do Risco

Risco n. Descrição do Risco

Impacto Probabilidade

Prioridade do Risco

custo cronograma escopo qualidade geral alta média Baixa

01

02

03

Impacto do risco no custo do projeto. 1. Aumento insignificante no custo (0,1)

2. Aumento no custo de

menos do que $ 1,00 por dia

(0,3)

3. Aumento no custo de $ 5,00

por dia (0,7)

4. Aumentode mais de R$

10,00 por dia (0,9)

I m p a c t o d o r i s c o n o cronograma do projeto. 1. Atraso insignificante no cronograma (0,1)

2. Atraso de menos de um dia

no cronograma (0,3)

3. Atraso de 5 a 10 dias no

cronograma

4. Atraso maior que 10 dias

no cronograma (0,9)

Impacto do risco no escopo do projeto. 1. Impacto insignificante no escopo do projeto (0,1)

2. Poucas entregas impactadas sem

efeito no aceite do projeto (0,3)

3. Algumas entregas impactadas

perceptíveis no aceite do projeto (0,5)

4. Impacto muito significante para o

cliente (0,7)

5. Inaceitável para o cliente (0,9)

Impacto do risco na qualidade do projeto. 1. Impacto insignificante na qualidade do projeto (0,1)

2. Poucas entregas impactadas sem

efeito no aceite do projeto (0,3)

3. Algumas entregas impactadas

perceptíveis no aceite do projeto (0,5)

4. Impacto muito significante para o

cliente (0,7)

5. Inaceitável para o cliente (0,9)

PROBABILIDADE D O R I S C O S E NENHUMA AÇÃO FOR TOMADA 1. Muito improvável de acontecer (0,1) 2. Mais provável de não acontecer do quea contecer (0,3) 3. Probabilidade de acontecer ou não é igual (0,5) 4. Mais provável de acontecer do que não acontecer (0,7) Muito provável que ocorra (0,9)


ANÁLISE QUANTITATIVA Avalia os impactos e quanLfica a exposição do projeto aos riscos por meio da atribuição de probabilidades numéricas a cada um e aos seus impactos sobre os objeLvos do projeto. Os objeLvos da análise quanLtaLva dos riscos são: 1)  QuanLficar os possíveis resultados e

probabilidades do projeto. 2)  Determinar a probabilidade de aLngir os objeLvos

do projeto 3)  IdenLficar riscos que requeiram maior atenção,

quanLficando sua contribuição para o riscos geral do projeto.

4)  IdenLficar metas de cronograma, custos ou escopo realistas e viáveis

5)  Tomar as melhores decisões possíveis de gerenciamento do projeto quando os resultados forem incertos.


ANÁLISE QUANTITATIVA FERRAMENTAS Existem dois conjuntos de instrumentos no processo de análise quanLtaLva: (1) coleta de dados e técnicas de representação e (2) técnicas de modelagem. Primeiro conjunto de Instrumentos de análise quanLtaLva de riscos Coleta de dados e técnicas de representação incluem entrevistas, distribuições de probabilidades e opinião especializada. 1) Entrevista: os interessados no projetos são os principais candidatos às entrevistas – geralmente são perguntados sobre suas experiências em projetos anteriores, sobre como trabalhar com novas tecnologias ou processos que serão uLlizados no projeto em pauta.


ANÁLISE QUANTITATIVA FERRAMENTAS 2) Distribuição de probabilidades: são triangulares usam esLmaLvas de três pontos – perspecLvas oLmistas, realistas e pessimistas. É um instrumento que é desenvolvido em conjunto com a entrevistas, onde deve se quesLonar aos stakeholders do projeto as informações serão uLlizadas na composição quanLtaLva dos riscos no projeto em questão. 3) Opinião especializada: os especialistas podem ser de dentro da empresa ou de fora e devem ter experiência técnica e aplicável ao projeto em questão. Neste caso podem ser uLlizado como instrumento auxiliar a técnica DELPHI.


Segundo conjunto de Instrumentos de análise quanLtaLva de riscos Análise quanLtaLva de riscos e técnicas de modelagem para representar esse conjunto de análise são elencados algumas técnicas (veremos)

1) Análise de Sensibilidade método de análise dos possíveis impactos dos eventos de risco sobre o projeto e a determinação de que evento de risco tem maior impacto potencial através da avaliação de elementos incertos em seus valores da linha de base. Uma das maneiras da apresentação dos dados da análise sensiLva é o DIAGRAMA DE TORNADO (PRÓXIMO SLIDE)


Análise quanLtaLva de riscos e técnicas de modelagem

2) Análise da árvore de decisão são diagramas que mostram a sequência de decisões inter-‐relacionadas e os resultados esperados de acordo com a alternaLva escolhida.

Decisão Início

A

B

R$ 4.200

R$ 2.800

R$ 4.000

R$ 1.000

Resultado pos

iLvo

Probabilidade

0,6

Resultado negaLvo Probabilidade 0,4

Resultado pos

iLvo

Probabilidade

0,8

Resultado negaLvo Probabilidade 0,2

VALOR ESPERADO DA DECISÃO

O valor esperado é o impacto previsto da decisão, expresso em Reais no caso ao lado. O valor esperado resulta da mulLplicação da probabilidade do evento do risco pelo impacto Os retângulos representam as decisões a serem tomadas e os círculos, os pontos em que os eventos dos riscos podem ocorrer. A DECISÃO COM UM VALOR ESPERADO DE R$ 7.000 É A MELHOR DECISÃO A TOMAR, UMA VEZ QUE O RESULTADO TEM VALOR MAIS ALTO


O monitoramento do controle de riscos em projetos é o processo de idenLficação, análise e planejamento dos riscos recém surgidos, acompanhamento dos riscos idenLficados e dos que estão na lista de observação, reanálises dos riscos existentes, monitoramento das condições de acionamento de planos de conLngência, e monitoramento dos riscos residuais. Ferramentos para Monitoramento e controle dos riscos 1.   Reavaliação de riscos -‐ controle roLneiro de riscos

conLngenciais. 2.   Auditoria de riscos – examinam e documentam a

eficácia das respostas aos riscos no tratamento dos riscos idenLficados e de suas causas-‐raiz, e também a eficária do processo de gerenciamento de riscos.

3.   Medição de desempenho técnico – compara as realizações técnicas durante a execução do projeto com o cronograma do plano de gerenciamento do projeto de realizações técnicas.


2) PROCESSO DE PLANEJAMENTO

3) PROCESSO DE EXECUÇÃO

4) PROCESSO DE MONITORAMENTO E CONTROLE

4) PROCESSO DE ENCERRAMENTO

Seminário – Project – Modelos Ágeis de Gestão de Projetos

Seminário de Gestão de Projetos

Unified'Process'(UP)'–'Processo'Unificado

Scrum'–'Processo'de'Desenvolvimento'Intera7vo'e'Incremental'de'Gerenciamento'de'Projetos

Extreme*Programming'(XP)'–'Programação'extrema

Feature*Driven'Development*(FDD)'Desenvolvimento'Guiado'por'Funcionalidades.

Agile*Project*Management*(APM)'C'Gerenciamento'Ágil'de'Projetos

Education

Gerenciamento de projetos de sistemas 2012.1