Fernando Nunes Lages

Tamanho: px
Começar a partir da página:

Download "Fernando Nunes Lages"

Transcrição

1 1 Fernando Nunes Lages MethodNula - Metodologia efetiva de gerenciamento de projetos de preço fixo com formação de equipes de alto desempenho e foco nas necessidades das partes interessadas Trabalho apresentado ao curso MBA em Gerenciamento de Projetos, Pós-Graduação lato sensu, da Fundação Getulio Vargas como requisito parcial para a obtenção do Grau de Especialista em Gerenciamento de Projetos. ORIENTADOR: Prof. André Valle Belo Horizonte 11/2012

2 2 FUNDAÇÃO GETULIO VARGAS PROGRAMA FGV MANAGEMENT MBA EM GERENCIAMENTO DE PROJETOS O Trabalho de Conclusão de Curso MethodNula - Metodologia efetiva de gerenciamento de projetos de preço fixo com formação de equipes de alto desempenho e foco nas necessidades das partes interessadas elaborado por Fernando Nunes Lages e aprovado pela Coordenação Acadêmica do curso de MBA em Gerenciamento de Projetos, foi aceito como requisito parcial para a obtenção do certificado do curso de pós-graduação, nível de especialização do Programa FGV Management. Local, Data André Bittencourt do Valle Coordenador Acadêmico Executivo André Bittencourt do Valle Professor Orientador

3 3 DECLARAÇÃO A empresa..., representada neste documento pelo Sr.(a)..., (cargo)..., autoriza a divulgação das informações e dados coletados em sua organização, na elaboração do Trabalho de Conclusão de Curso intitulado (título)..., realizados pelo(s) aluno(s)..., do curso de MBA em Gerência de Projetos, do Programa FGV Management, com o objetivo de publicação e/ ou divulgação em veículos acadêmicos. Local, Data (assinatura) (cargo) (Empresa)

4 4 TERMO DE COMPROMISSO O(s) aluno(s) Fernando Nunes Lages, abaixo assinado(s), do curso de MBA em Gerenciamento de Projetos, PROJTI-03 do Programa FGV Management, realizado nas dependências da (Instituição conveniada)..., no período de dd/mm/aa a dd/mm/aa, declara que o conteúdo do Trabalho de Conclusão de Curso intitulado (título)..., é autêntico, original e de sua autoria exclusiva. Belo Horizonte, Data Fernando Nunes Lages

5 5 Dedicatória A minha esposa que me apoiou nos grandes períodos de tempo que gastei na formação deste trabalho e pelo incentivo de aprofundar nos meus estudos. A minha família, que conduziu o meu caráter e deu suporte para a minha formação. Aos meus superiores e funcionários que tiveram a paciência e motivação de experimentar as ferramentas propostas nesta metodologia, meu laboratório. Aos professores que compartilharam dos seus conhecimentos de forma embasada, real e viva. Deve-se ter em mente que não há nada mais difícil de executar, nem de sucesso mais duvidoso, nem mais perigoso de se conduzir, do que iniciar uma nova ordem de coisas. Nicolau Maquiavel

6 6 RESUMO Palavras Chave:

7 7 ABSTRACT Key Words:

8 AGRADECIMENTOS 8

9 9 SUMÁRIO 1. INTRODUÇÃO CONSIDERAÇÕES INICIAIS OBJETIVO RELEVÂNCIA CONSIDERAÇÕES FINAIS FUNDAMENTAÇÃO TEÓRICA CONSIDERAÇÕES INICIAIS GERENCIAMENTO DE PROJETOS PARTES INTERESSADAS (STAKEHOLDERS) METODOLOGIA DO GERENCIAMENTO DE PROJETOS CICLO DE VIDA DE UM PROJETO PMBOK GUIDE PROJECT MANAGEMENT INSTITUTE (PMI) INTRODUÇÃO AO PMBOK GUIDE ÁREAS DE CONHECIMENTO GERENCIAMENTO DE INTEGRAÇÃO DO PROJETO GERENCIAMENTO DO ESCOPO DO PROJETO GERENCIAMENTO DE TEMPO DO PROJETO GERENCIAMENTO DE CUSTOS DO PROJETO GERENCIAMENTO DA QUALIDADE DO PROJETO GERENCIAMENTO DE RECURSOS HUMANOS DO PROJETO GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO GERENCIAMENTO DE RISCOS DO PROJETO GERENCIAMENTO DE AQUISIÇÕES DO PROJETO GRUPOS DE PROCESSOS ESCOPO ESCOPO DO PRODUTO E ESCOPO DO PROJETO ESTRUTURA ANALÍTICA DO PROJETO EAP RISCOS... 28

10 IDENTIFICAR OS RISCOS ANÁLISE QUALITATIVA DE RISCOS RESTRIÇÕES E PREMISSAS CRONOGRAMA E CUSTOS DO PROJETO IDENTIFICAR ATIVIDADES DURAÇÃO DAS ATIVIDADES SEQUENCIAMENTO DE ATIVIDADES CRONOGRAMA ESTIMATIVA DE CUSTOS COMUNICAÇÃO COMUNICAÇÃO INFORMAL REUNIÕES MAPA DE COMUNICAÇÃO EQUIPES EQUIPES DE ALTO DESEMPENHO FASES DE FORMAÇÃO DAS EQUIPES DE ALTO DESEMPENHO LÍDER DISTRIBUIR RESPONSABILIDADES QUALIDADE IDENTIFICANDO E PRIORIZANDO OS CLIENTES IDENTIFICANDO E PRIORIZANDO AS NECESSIDADES POR CLIENTE PRIORIZANDO AS NECESSIDADES DO PROJETO MÉTODOS ÁGEIS FEEDBACK PARTICIPAÇÃO ATIVA DO CLIENTE VALOR AGREGADO PRIORIZAÇÃO DAS ENTREGAS PRIORIZAÇÃO PELA TÉCNICA KANO COMO UTILIZAR KANO KANBAN TIPOS DE CONTRATOS CONSIDERAÇÕES FINAIS METODOLOGIA CIENTÍFICA... 62

11 3.1. CONSIDERAÇÕES INICIAIS METODOLOGIA CONSIDERAÇÕES FINAIS ANÁLISE DOS DADOS CONSIDERAÇÕES INICIAIS COMPARATIVO COM O PMBOK GUIDE COMPARATIVO COM OS MÉTODOS ÁGEIS COMPARATIVO COM GESTÃO DE PESSOAS INTRODUÇÃO QUANTO A METODOLOGIA ESCOPO DA METODOLOGIA MOMENTOS PRÉ-VENDA PLANEJAMENTO EXECUÇÃO ENCERRAMENTO ENTENDENDO A NOVA METODOLOGIA PARTES INTERESSADAS PARTICIPAREM DO PROCESSO EQUIPE PARTICIPAR DO PROCESSO RESPONSABILIDADES ARTEFATOS E ENTREGAS PROCESSOS INICIAÇÃO ELABORAR A PROPOSTA IDENTIFICAR AS PARTES INTERESSADAS DEFINIR O ESCOPO E O MAPA DO PRODUTO CRIAR MAPA DO PROJETO (EAP) ESTIMAR TEMPO ESTIMAR CUSTOS PLANEJAMENTO CLASSIFICAR PROJETO ANALISAR MÚLTIPLOS PROJETOS E DEFINIR EQUIPE PLANEJAR AQUISIÇÕES E ADQUIRIR

12 CRIAR CRONOGRAMA FORMAR EQUIPE, LÍDER E NEGOCIADOR EQUIPE PLANEJAR A QUALIDADE EQUIPE PLANEJAR OS RISCOS PLANEJAR A COMUNICAÇÃO ORGANIZAR RESPONSABILIDADES E PLANO DO PROJETO STAKEHOLDERS PARTICIPAREM DO PLANEJAMENTO EXECUÇÃO CRIAR PROTÓTIPO E DESIGN DO PRODUTO EQUIPE FORMAR O KANBAN COM ENTREGAS SEMANAIS EQUIPE GERENCIAR A EXECUÇÃO DISTRIBUIR AS INFORMAÇÕES GARANTIR A QUALIDADE DESENVOLVER A EQUIPE DO PROJETO CONTROLE CONTROLAR O ANDAMENTO DO PROJETO EQUIPE GERENCIAR MUDANÇAS EQUIPE CONTROLAR A QUALIDADE E OS RISCOS GERENCIAR AS PARTES INTERESSADAS E A EQUIPE DO PROJETO ADMINISTRAR AQUISIÇÕES ENCERRAMENTO APRESENTAR PARTES DO PRODUTO ENCERRAR PROJETO ENCERRAR AQUISIÇÕES ENCERRAR ESTRATÉGICO DO PROJETO (QUAIS OUTROS PROJETOS PODEM SER GERADOS + O QUE PODE SER LIBERADO PARA A COMUNIDADE + ALTERAR O PROCESSO COM AS LIÇÕES APRENDIDAS) CONCLUSÕES POSSÍVEIS DESDOBRAMENTOS

13 7. REFERÊNCIAS BIBLIOGRÁFICAS GLOSSÁRIO APÊNDICES APÊNDICE A FORMULÁRIO DE AVALIAÇÃO DE DESEMPENHO LISTA DE FIGURAS E TABELAS Tabela 2: IP Indices Suporte ao Negócio - Geral Erro! Indicador não definido.

14 14 1. INTRODUÇÃO 1.1. Considerações Iniciais Não há relato de qual foi o primeiro projeto na história, mas é fato e de conhecimento popular que a humanidade sempre realizou projetos, como exemplo na construção de casas e navios, realização de eventos e casamentos, descobrimento terrestre e espacial, criação de novos produtos e leis entre outros. Os projetos existem onde há mudanças e pode-se dizer que tudo que se cria passa-se por um momento chamado projeto. E sobre esta ótica, vemos no atual cenário os projetos tornando vitais para as corporações, já que a inovação é o tema central das economias, porque é a base da estratégia genérica da diferenciação de Porter, e em contextos hiper-competitivos, a inovação é a única arma que as empresas têm para procurar novos mercados e resistirem à pressão da concorrência (anônimo, A partir disso observam-se, no mínimo, dois fenômenos dos tempos atuais, primeiro que as empresas tendem a ser porosas, maleáveis e inovadoras (BELLO, 2012) criando um cenário de constantes mudanças internas, e o segundo é o surgimento da Onda Beta (COGHI, 2012), onde os projetos estão sendo constantemente testados e lançados, promovendo um período projetando maior que o período operando. Esta necessidade de projetos e empresas mutáveis chega acrescentando complexidade ao que já existe que são os projetos tradicionais e toda sua bagagem histórica. Para que haja tantos projetos e estes existindo em tantos ambientes e situações, criaramse do gerenciamento de projetos estudos e metodologias de trabalho, que descrevem uso de ferramentas, técnicas e métodos que vêm sendo catalogados por anos e vindos de diversas áreas da sociedade. Tal fato fortalece o conceito de que utilizar uma mesma metodologia para todos os projetos não é recomendado, pois gera um descompasso entre a metodologia e o trabalho necessário (CURI, 2009, p. 15). Por exemplo, uma metodologia ágil que é orientada a mudanças não é adequada no gerenciamento de projetos orientados ao planejamento, ao mesmo tempo em que uma metodologia para projetos de preço fixo não encaixa em projetos

15 de escopo aberto e exemplifica-se também uma metodologia simplificada que é ótima para projetos pequenos, mas inadequada para projetos médios ou grandes. Por isso, escolher a metodologia adequada para cada projeto aumenta a chance de sucesso. Este trabalho propõe a desenvolver uma metodologia efetiva para o gerenciamento de projetos de preço fixo com formação de equipes de alto desempenho e foco nas necessidades das partes interessadas. Ele está estruturado em 2 capítulos principais: Fundamentação Teórica e Análise dos dados, além da Introdução, Conclusões, Possíveis Desdobramentos, Referências Bibliográficas e Apêndices. No capítulo Fundamentação Teórica são apresentados os conceitos base do gerenciamento de projetos, o gerenciamento de projetos do PMBOK Guide (2008) detalhando o gerenciamento de riscos, tempo e custos. Também são aprofundados estudos relacionados a comunicação, equipes, qualidade, métodos ágeis e kanban. No capítulo análise dos dados é apresentada a nova metodologia de gerenciamento de projetos baseada no MethodWare (XAVIER, 2009), no PMBOK Guide (2008) e nos métodos ágeis. Neste capítulo, encontra-se a parte mais importante do trabalho que é a descrição detalhada dos processos que compõem a nova metodologia Objetivo O objetivo é apresentar uma metodologia completa, já com o ciclo de vida definido, para o gerenciamento de projetos com preço fixo e que aumente suas chances de sucesso com uso de equipes de alto desempenho e buscando constantemente em atender as necessidades das partes interessadas com destaque para as ferramentas de comunicação e de alinhamento das expectativas. E de forma efetiva orientando as ações e recursos em busca do melhor resultado (eficácia), desenvolvendo as atividades no melhor padrão de qualidade versus tempo (eficiência) Relevância Em um cenário competitivo e conectado como o atual, as mudanças, os baixos custos, os curtos prazos e a alta qualidade são restrições comuns quando se trata em planejar projetos. Tais necessidades podem ser alcançadas organizando ferramentas, técnicas e métodos que

16 estimulam a participação ativa do time do projeto e das demais partes interessadas nas decisões e no gerenciamento da criação do produto. Para tanto, é importante colocar em prática estudos e técnicas que tornem os membros do projeto altamente motivados e competentes, capazes de fazer muito com pouco, sem necessitarem de grande supervisão e utilizar ao máximo a multidisciplinaridade deles. Sendo assim, uma proposta desta metodologia é a definição e distribuição das responsabilidades para e pelo time objetivando a criação de equipes conhecidas como de alto desempenho. Outra proposta é a participação ativa do patrocinador nos processos objetivando atender suas necessidades e trazendo um alto valor agregado, sendo ele a pessoa que mais conhece os impactos que certos caminhos e decisões no projeto trazem ao negócio. Também são utilizadas técnicas de gestão a vista e as melhores práticas na gestão de riscos, qualidade, comunicação e aquisições advindas do livro PMBOK Guide (PMI, 2008). Para redução dos custos e hierarquias utilizou-se técnicas como entregas cíclicas, formação de equipes auto gerenciáveis, comunicação informal e aprendizado constante. É importante dizer que a comunicação está no centro da construção desta metodologia, isto porquê de acordo com o PMI (Project Management Institute), órgão mundial especializado em projetos, a falha em comunicação causa os problemas mais frequentes em projetos, como pode ser visto no gráfico abaixo: 16 Gráfico X: Problemas mais frequentes em projetos Fonte: Relatório Principal Perspectiva Geral Estudo de Benchmarking em Gerenciamento de Projetos 2009, Project Management Institute Chapters Brasileiros acessado em

17 Esta pesquisa ainda indica que o principal motivo das falhas de comunicação está na questão de habilidades interpessoais. Por isso, fica evidente a necessidade de criar um ambiente que incentive tais habilidades. De fato, quando o patrocinador participa do processo, o projeto sofre diversas entregas reduzidas, a equipe toma decisões, a equipe comunica diretamente com o patrocinador, o ambiente possui gestão a vista, e o objetivo e as regras é claro para todos, que é a proposta desta metodologia, a comunicação tende a melhorar Considerações finais Este capítulo de introdução mostrou o objetivo e a relevância deste trabalho. No próximo capítulo será abordada a fundamentação teórica necessária ao desenvolvimento da nova metodologia de gerenciamento de projetos. 2. FUNDAMENTAÇÃO TEÓRICA 2.1. Considerações Iniciais Este capítulo tem por objetivo revisar a literatura e analisar as informações já publicadas por outros autores sobre o que é um projeto e suas metodologias de gerenciamento. Aqui são descritos os principais conceitos e processos do PMBOK Guide (2008), os princípios dos métodos ágeis e os estudos em riscos, comunicação, equipe e qualidade que estão relacionados à nova metodologia. Este referencial teórico foi obtido através do levantamento bibliográfico: leitura de livros, mídia eletrônica, periódicos, artigos, dissertações e relatórios de pesquisa Gerenciamento de projetos Nos dias atuais onde tudo se transforma tão rapidamente, mudanças são cada vez mais frequentes em nossas vidas, e sempre que ocorrem, as reestruturações se fazem necessárias, e estas exigem projetos. De acordo com o PMI (2008) um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

18 São sistemas ou sequências de atividades finitas, com começo, meio e fim bem definidos, com objetivos de fornecer um produto. Esse produto se caracteriza como o escopo do projeto que é o que se deseja alcançar e o objetivo do projeto (Maximiano, 2006). Gerenciar projetos consiste em aplicações de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender às suas demandas, sendo realizado por meio da integração dos seguintes processos: iniciação, planejamento, monitoramento e controle, e encerramento (PMI, 2008). Sua aplicação ao longo de todo o trabalho permite a avaliação do desempenho, o aprendizado contínuo e a antecipação do desempenho futuro com razoável confiabilidade (XAVIER, 2009, p. 7). O responsável pelo gerenciamento de projetos é o gerente de projetos, que é a pessoa responsável pelo planejamento, implantação e encerramento do projeto. (RAJ, 2006, p. 35). As atribuições do gerente de projetos são (VALLE, 2007, p. 35): A identificação das necessidades do projeto; O estabelecimento de objetivos claros e palpáveis; O atendimento às expectativas de todas as partes interessadas; O devido balanceamento entre qualidade, escopo, tempo e custo. Os gerentes de projeto possuem responsabilidades e habilidades que variam em grau de importância de projeto para projeto ou até de situação para situação. Os papeis não são o mesmo que os títulos dos cargos de um plano de cargos e salários de uma organização; eles estão muito mais atrelados às características do trabalho ou do projeto do que as que estão formalmente descritas na sua função. (RAJ, 2006, p. 39) RAJ (2006, p. 40) completa montando o seguinte quadro com os papéis e responsabilidades do gerente de projetos: 18 Papéis Interpessoais (líder, pessoa de referência, contato entre pessoas). Comunicação (coletar, selecionar, monitorar e disseminar informações; porta-voz do Responsabilidades Gerenciar o projeto Criar planos de projetos. Criar vários planos de gerencia do projeto. Medir o desempenho do projeto.

19 19 projeto). Decisão (alocar recursos, explorar novas oportunidades, gerir conflitos, negociar, analisar situações, estabelecer prioridades, tomar decisões coerentes e oportunas para encorajar a criatividade e o progresso da equipe). Adotar medidas corretivas. Controlar os resultados do projeto. Gerenciar a equipe do projeto. Prover relatórios de status do projeto. Tabela X: Papéis e responsabilidades do gerente de projetos Fonte: RAJ, 2006, p Partes Interessadas (stakeholders) As pessoas, grupos de pessoas e organizações que estão ativamente envolvidas no projeto ou, então, cujos interesses possam ser afetados de forma positiva ou negativa como resultado da execução ou conclusão do projeto, são chamadas de stakeholders. Eles podem também exercer influência sobre o projeto e seus resultados (XAVIER, 2009, p. 7). Os stakeholders são as partes interessadas pelo projeto. As partes interessadas podem incluir clientes, fornecedores, vendedores, usuários finais, equipe do projeto ou outros membros do seu grupo e outras partes interessadas; elas podem ser internas ou externas à organização ou grupo. Sua responsabilidade pode variar de contribuições ocasionais até o patrocínio completo. (PMI, 2006, p. 6). Podemos classifica-las em três tipos (VALLE, 2007, p. 113): Patrocinadores (sponsor): investidores, diretores, superintendentes, clientes (externos e internos); Participantes: gerente de projetos, equipe de projetos, agências reguladoras, fornecedores, empreiteiros, especialistas etc.; Externos: ambientalistas, líderes e grupos de comunidades, mídia, familiares dos integrantes do projeto etc Metodologia do gerenciamento de projetos A metodologia determina quais entregas específicas de gerenciamento de projetos necessitam ser realizadas em um dado momento, possivelmente fornecendo modelos de

20 documentos e disponibilizando ferramentas aceleradoras para a sua execução (VALLE, 2007, p. 75). Não se admite minimizar a importância de uma boa metodologia. Além de melhorar o desempenho durante a execução do projeto, ela criará, igualmente, as condições para aumentar a confiança dos clientes e, assim, aperfeiçoar o relacionamento com eles (KERZNER, 2006, p. 102). KERZNER (2006) diz que a implantação de uma metodologia de gerência de projetos em uma empresa deve ser feita em 5 fases: embrionária (reconhecer importância), aceitação pela gerência executiva, aceitação pelos gerentes da área, crescimento e maturidade. A fase de crescimento possui as seguintes etapas: Estabelecimento das fases do ciclo de vida; Desenvolvimento de uma metodologia de gestão de projetos; Fundamentação da metodologia para um planejamento efetivo; Minimização da ocorrência de mudanças; Seleção do software apropriado para sustentar a metodologia; É evidente a importância de se ter uma metodologia, mas o fato de tê-la não garante sucesso e excelência. A necessidade de aperfeiçoamentos no sistema pode ser crítica. Além disso, fatores externos podem representar forte influência no sucesso ou no fracasso da metodologia de gestão de projetos de uma organização (KERZNER, 2006, p. 103). A metodologia deve sempre ser atualizada acompanhando o mercado Ciclo de vida de um projeto XAVIER (2009, p. 8) diz que para melhor planejar, executar e controlar um projeto, nós o dividimos em pedaços menores que denominamos fases. A execução sequencial destas fases, num formato cronológico, representa o ciclo de vida do projeto. Cada projeto pode ter suas próprias definições de fases, não existe uma única maneira de definir o ciclo de vida do projeto já que a variação depende do tipo do produto e até do ambiente empresarial. Por exemplo, em desenvolvimento de sistemas existe a fase Teste Alpha e a fase Teste Beta, em agências digitais existe a fase criação da identidade visual e criação do

21 conteúdo, em um projeto de realização de um coquetel existe a fase preparar evento e realizar evento e etc PMBOK Guide Este tópico apresenta conceitos básicos do PMI e do PMBOK Guide, e entra mais a fundo nos grupos de processos, nas áreas de conhecimento, na EAP (estrutura analítica do projeto), no cronograma, nos custos e na gestão de riscos que são referencial teórico para os capítulos sequentes Project Management Institute (PMI) Criado em 1969 e sediado na Filadelfia (EUA), o Project Management Institute (PMI) é uma das principais associações mundiais em gerenciamento de projetos com mais de 420 mil associados e certificados em todo o mundo (VALLE, 2007, p. 37). Desde 1984 o PMI tem se dedicado a desenvolver e manter um rigoroso programa de certificação profissional para promover o crescimento da profissão de gerenciamento de projetos e reconhecer as realizações de indivíduos no tema. A certificação de Project Management Professional (PMP ) é a credencial mais reconhecida mundialmente para indivíduos envolvidos com o gerenciamento de projetos (CURI, 2009, p. 19) Introdução ao PMBOK Guide Criado em 1986 e estando em sua quarta edição desde 2008 o Project Management Body of Knowledge ou PMBOK foi desenvolvido e é mantido pelo PMI - Project Management Institute. O PMBOK fornece um conjunto de conhecimentos em gerenciamento de projetos reconhecido internacionalmente e em diversas áreas específicas de trabalho (VALLE, 2007, p. 39) e é reconhecido por ter descrito as melhores práticas em gestão de projetos. É um guia genérico não estando restrito a nenhuma área, como por exemplo, desenvolvimento de sistemas, e também é flexível no sentido de não tornar obrigatório o uso de todas as práticas, permitindo que empresas e setores adaptem a gestão de projetos de modo mais suave e prático.

22 22 O PMBOK, com seus 42 processos de gerenciamento de projetos, não é considerado uma metodologia, porque descreve processos de alto nível sem prescrever especificamente como devem ser implantados (VALLE, 2007, p. 75). O conhecimento de gerenciamento de projetos descrito no PMBOK (PMI, 2008) consiste em: Cinco grupos de processos de gerenciamento de projetos. Oito áreas de conhecimento mais a integração entre elas. 42 processos Áreas de conhecimento Os 42 processos do PMBOK são categorizados por áreas de conhecimento. No total, são oito áreas de conhecimento: escopo, tempo, custos, qualidade, recursos humanos, comunicações, riscos, aquisições e a coordenação destas áreas é responsabilidade de uma nona, denominada integração Gerenciamento de integração do projeto São os processos que integram os diversos elementos do gerenciamento de projetos, que são identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos de gerenciamento de projetos (XAVIER, 2009, p. 8). Processos do gerenciamento da integração (CURI, 2009, p. 26): Desenvolver o Termo de abertura do projeto (Project Charter): desenvolve o documento que formalmente autoriza o projeto. Desenvolver o plano de gerenciamento do projeto: é o processo necessário para integrar e coordenar todos os planos auxiliares em um plano de gerenciamento do projeto. Orientar e gerenciar a execução do projeto: desenvolve o trabalho definido no Plano de Gerenciamento do Projeto para atingir os objetivos do projeto. Monitorar e controlar o trabalho do projeto: envolve acompanhar, revisar e regulamentar o progresso do projeto para atingir seus objetivos. Controle integrado de mudanças: é o processo de revisão, aprovação e gerenciamento de todas as requisições de mudança. Encerrar o projeto ou fase: finaliza todas as atividades em todos os processos para encerrar formalmente o projeto.

23 Gerenciamento do escopo do projeto São os processos envolvidos na verificação de que o projeto inclui todo o trabalho necessário, e apenas o trabalho necessário, para que seja concluído com sucesso (XAVIER, 2009, p. 8). Processos do gerenciamento do escopo (CURI, 2009, p. 27): Coletar Requisitos: define e documenta as necessidades dos interessados para atingir os objetivos do projeto. Definição do escopo: desenvolve uma descrição detalhada do projeto e do produto. Criar a EAP Estrutura Analítica do Projeto: subdivide as entregas do projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis. Verificação do escopo: é a aceitação formal das entregas completas do projeto Controle do escopo: monitora o escopo do produto e do projeto e as suas mudanças Gerenciamento de tempo do projeto São os processos necessários para que haja o término do projeto no prazo correto (XAVIER, 2009, p. 8). Processos do gerenciamento do tempo (CURI, 2009, p. 27): Definição das atividades: identifica as atividades que precisam ser realizadas para produzir as entregas do projeto. Seqüenciamento das atividades: identifica as dependências entre as atividades do projeto. Estimativa de recursos das atividades: estima o tipo e a quantidade de material, pessoas, equipamentos e fornecimentos necessários para realizar cada atividade. Estimativa de duração das atividades: estimar o número de períodos de trabalho que serão necessários para terminar as atividades. Desenvolvimento do cronograma: analisa os recursos necessários, restrições, durações e seqüências das atividades para criar o cronograma do projeto. Controle do cronograma: monitora o status, controla as mudanças e atualiza o progresso do cronograma em relação ao seu baseline.

24 Gerenciamento de custos do projeto São os processos envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que o projeto termine dentro do orçamento aprovado (XAVIER, 2009, p. 8). Processos do gerenciamento de custos (CURI, 2009, p. 28): Estimativa dos custos: é o processo necessário para desenvolver uma aproximação dos custos dos recursos necessários para terminar as atividades do projeto. Orçamentação: agrega os custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base (baseline) dos custos. Controle dos custos: monitora o status, controla as mudanças e atualiza o progresso do orçamento em relação ao seu baseline Gerenciamento da qualidade do projeto São os processos envolvidos na garantia de que o projeto irá satisfazer os objetivos para os quais foi realizado (XAVIER, 2009, p. 8). Processos do gerenciamento da qualidade (CURI, 2009, p. 28): Planejamento da qualidade: é o processo necessário para identificar os padrões de qualidade relevantes para o projeto e determinar como satisfazê-los. Realizar a garantia da qualidade: audita os requerimentos e indicadores da qualidade para garantir que os padrões de qualidade definidos estão sendo usados. Realizar o controle da qualidade: monitora e grava os resultados da execução das atividades para avaliar o desempenho e recomendar mudanças necessárias Gerenciamento de recursos humanos do projeto São os processos que organizam e gerenciam a equipe do projeto (XAVIER, 2009, p. 8). Processos do gerenciamento de recursos humanos (CURI, 2009, p. 28): Planejamento de recursos humanos: identifica e documenta funções, responsabilidades e relações hierárquicas do projeto, além de criar o plano de gerenciamento de pessoal. Adquirir a equipe do projeto: obtém os recursos humanos necessários para terminar o projeto. Desenvolver a equipe do projeto: é o processo necessário para melhorar as competências e a interação de membros da equipe para aprimorar o desempenho do projeto.

25 25 Gerenciar a equipe do projeto: acompanha o desempenho da equipe, fornece feedback e resolve questões e gerencia mudanças para otimizar o desempenho do projeto Gerenciamento das comunicações do projeto São os processos relativos à geração, coleta, disseminação, armazenamento e destinação final das informações do projeto de forma oportuna e adequada (XAVIER, 2009, p. 8). Processos do gerenciamento das comunicações (CURI, 2009, p. 29): Identificar as partes interessadas: identifica as pessoas e organizações impactadas pelo projeto. Planejamento das comunicações: determina as informações necessárias dos interessados do projeto e define a forma de comunicação. Distribuição das informações: distribui as informações relevantes aos interessados conforme o planejado. Relatar o desempenho: é o processo de coletar e distribuir informações sobre o desempenho, incluindo relatório de status, medição do progresso e previsão. Gerenciar as Partes interessadas: comunica e trabalha com os interessados para atingir seus objetivos e resolve suas questões quando ocorrerem Gerenciamento de riscos do projeto São os processos relativos à realização do gerenciamento das ameaças e oportunidades em um projeto (XAVIER, 2009, p. 8). Processos do gerenciamento de riscos (CURI, 2009, p. 29): Planejamento do gerenciamento de riscos: é o processo que define como conduzir o gerenciamento dos riscos do projeto. Identificação dos riscos: identifica quais riscos podem afetar o projeto e documenta suas características. Análise qualitativa dos riscos: prioriza os riscos através de avaliação e combinação de sua probabilidade de ocorrência e impacto. Análise quantitativa dos riscos: analisa numericamente o efeito dos riscos identificados nos objetivos gerais do projeto. Planejamento de respostas aos riscos: desenvolve opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto.

26 26 Monitoramento e controle dos riscos: acompanha os riscos identificados, monitora os riscos residuais, identifica novos riscos, executa planos de respostas a riscos e avalia sua eficiência durante todo o projeto Gerenciamento de aquisições do projeto São os processos que compram ou adquirem produtos, serviços ou resultados, além dos necessários ao gerenciamento de contratos (XAVIER, 2009, p. 8). Processos do gerenciamento de aquisições (CURI, 2009, p. 29): Planejar aquisições: determina o que comprar ou adquirir e quando e como fazer isso e identifica fornecedores em potencial. Conduzir aquisições: obtém resposta dos fornecedores, seleciona e realiza contratos. Administrar as Aquisições: é o processo de gerenciar as relações comerciais, monitorar o desempenho do contrato e fazer mudanças e correções, se necessário. Encerrar as Aquisições: termina e liquida cada contrato do projeto Grupos de Processos Os processos de gerenciamento de projetos garantem o fluxo eficaz do projeto ao longo de sua existência. Esses processos abrangem as ferramentas e as técnicas envolvidas na aplicação de habilidades e capacidades descritas nas áreas de conhecimento (PMI, 2008). O PMBOK possui 42 processos que estão integrados e organizados em cinco grupos. É importante entender que os grupos de processos são diferentes dos ciclos de vida de um projeto (ver tópico 2.2.3). Os cinco grupos de processos são (VALLE, 2007, p. 75): Iniciação: processo que formaliza a existência do projeto para a organização, define seus objetivos e seu escopo inicial, nomeia o gerente de projeto e autoriza a mobilização de recursos da organização para sua realização; Planejamento: processo que determinará, com um melhor grau de precisão, o que deve ser feito, por meio da declaração de escopo, e como deve ser feito, por meio de um plano de gerenciamento de projeto. Essas definições são registradas em uma linha base, que é um plano contra o qual os resultados serão conferidos; Execução: produção das entregas do projeto por meio da integração de pessoas, organizações e recursos materiais;

27 Monitoramento e controle: conferência dos resultados da execução com a linha de base definida no planejamento. No caso de desvios, ações corretivas devem ser tomadas; Encerramento: processo que formaliza o encerramento do projeto, o aceite dos resultados obtidos, o encerramento oficial de contratos e a desmobilização da equipe; No tópico são apresentados em qual grupo cada um dos 42 processos faz parte Escopo Antes de entender o escopo é importante saber que requisitos são desejos, necessidades e expectativas de sua equipe, cliente, ou demais stakeholders. O escopo é uma visão de onde pretende chegar e sua base foi moldada pelo uso de ferramentas, técnicas e processos em cima dos requisitos. Portanto se algum desejo, necessidade ou expectativa for alterado com o tempo, existe uma grande chance do escopo também ser alterado. O escopo é todo o trabalho a ser realizado no projeto Escopo do produto e escopo do projeto Existem dois tipos de escopo: o do produto e o do projeto. O escopo do produto está relacionado ao conjunto de características e funções que descrevem um produto, serviço ou resultado, seja ele parcial ou final. Está intimamente relacionado aos requisitos e especificações fornecidos pelo cliente e por outras partes interessadas (SOTILLE, 2010, p. 24). Já o escopo do projeto refere-se ao trabalho que deve ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas (SOTILLE, 2010, p. 24). De acordo com XAVIER (2009, p. 43) o escopo do projeto é maior que o escopo do produto.

28 Estrutura Analítica do Projeto EAP A estrutura analítica do projeto ou EAP representa todo o escopo do projeto de uma forma visual, o que facilita a comunicação com todos os envolvidos no projeto. Na EAP as atividades do projeto não são exibidas e sim grupos de atividades comumente chamados de pacotes de trabalho, isso reduz o excesso de informação que pode prejudicar na comunicação. De acordo com o PMI (2008, p. 116), ela representa uma decomposição hierárquica orientada às entregas do trabalho a ser executada pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas, sendo que cada nível descendente da EAP representa uma definição gradualmente mais detalhada da definição do trabalho do projeto. SOTILLE (2010, p. 92) completa dizendo que por meio de estrutura semelhante a um organograma, a EAP representa o que deverá ser entregue pelo projeto. Ela permite detalhar quais as entregas que devem ser geradas em função dos objetivos do projeto. Se o escopo representa todo o trabalho a ser feito no projeto, a EAP é a ferramenta visual que representa o escopo e por isso é importante que ela seja feita e seja completa. O exemplo de uma EAP é apresentado no tópico , que esta metodologia chama de mapa do projeto Riscos Riscos são eventos incertos que podem ocorrer ou não e, seguramente, vão afetar os objetivos do projeto. Não temos certeza se vão ocorrer ou não, e não temos certeza em que grau eles vão ocorrer (SALLES, 2010, p. 28). Não sabemos se ele vai ocorrer, o que podemos chamar de probabilidade e nem sabemos em que grau eles vão ocorrer que, somado ao dano causado, podemos chamar de impacto. Outro ponto a notar é que os riscos, por serem incertos, podem ser positivos ou negativos. Gerenciamento de riscos é o processo de identificação, análise, desenvolvimento de respostas e monitoramento dos riscos em projetos, com o objetivo de diminuir a probabilidade e o impacto de eventos negativos e de aumentar a probabilidade e o impacto de eventos positivos. (PMI, 2008). Todo risco tem, obrigatoriamente, três componentes (SALLES, 2010, p. 30):

29 O evento em si, no qual deve ser identificada a causa raiz (fonte) do risco, bem como seu efeito (consequência); Uma probabilidade associada; Um impacto; Todos os aspectos que constituem um projeto, ou seja, tecnologia, recursos humanos e materiais, aspectos legais, políticos, ambientais e financeiros, podem ser fontes de riscos (XAVIER, 2009, p. 85) Identificar os riscos O primeiro passo é identificar os riscos, e quem deve fazer este trabalho é o grupo de pessoas mais interessadas no projeto. A identificação inicial dos riscos é feita por um grupo de pessoas, que geralmente representam os principais stakeholders, selecionado pelo gerente do projeto a partir da análise das partes interessadas. Entretanto, no decorrer do projeto, todos os membros da equipe devem ser responsáveis por identificar e caracterizar novos riscos, em função do progresso do projeto ou de mudanças no seu ambiente (XAVIER, 2009, p. 87). De acordo com SALLES (2010, p. 28) a identificação inicial é feita em três etapas distintas e complementares, podendo ser realizado por meio de várias rodadas. São elas: analogia com projetos anteriores, categorização dos riscos e identificação de novos riscos. Para a identificação de novos riscos devemos olhar para diversas áreas, como (SALLES, 2010, p. 44): Cada item do escopo é uma fonte potencial de riscos; Cada caixa da EAP é uma fonte potencial de riscos; Cada atividade do cronograma é uma fonte potencial de riscos; Cada recurso do orçamento é uma fonte potencial de riscos; Cada área de conhecimento: integração, escopo, prazos, custos, recursos humanos, comunicações, qualidade e aquisições; E para identificar riscos nestas áreas são utilizadas ferramentas e técnicas de dinâmica em grupo.

30 A técnica mais utilizada é o brainstorming (tempestade de idéias), onde um grupo de pessoas fala o que lhes vem à mente, ou seja, qualquer risco é bem vindo e, geralmente, o gerente de projetos conduz a reunião mantendo as regras que são: Permitir que todos falem sem serem questionados; Fazer com quê toda ideia seja aceita; A técnica mais conhecida, certamente, é o brainstorming, em que um facilitador (geralmente o gerente de projetos) conduz uma reunião de dinâmica de geração de ideias, neste caso visando à identificação dos riscos do projeto. A ideia central desta técnica é a carona na ideia do outro (SALLES, 2010, p. 45) Análise qualitativa de riscos Todo risco tem probabilidade que não é zero (certeza da não ocorrência) e nem 100% (certeza total da ocorrência, um fato) e, caso ocorra, provocará um impacto. Para trabalhar com riscos é necessário medi-lo, dando peso, a estes dois componentes. Para cada evento de risco identificado, deve ser feita uma análise de probabilidade deste ocorrer e do impacto que causaria sobre os objetivos do projeto, caso isso acontecesse. Devem ser utilizados critérios qualitativos (por exemplo: desprezível, baixo, moderado, alto e muito alto) para se avaliarem essas duas dimensões do risco, utilizando-se as escalas de probabilidade e impacto (XAVIER, 2009, p. 87). Os critérios qualitativos são subjetivos, cada pessoa informa a nota que julgar correta. Cada participante da análise qualitativa deve avaliar os riscos quanto às suas probabilidades e impactos. A avaliação final será obtida pela média das avaliações individuais (XAVIER, 2009, 92). Para SALLES (2010, p. 64), em cada análise qualitativa, é importante estabelecer previamente uma escala numérica para conversão da escala ordinal, de forma a possibilitar a geração de gráficos e pesos para os riscos. E segue dando os seguintes exemplos: Probabilidade: muito alta (0,9), alta (0,7), moderada (0,5), baixa (0,3), muito baixa (0,1); Impacto: muito alto (0,9), alto (0,7), moderado (0,5), baixo (0,3), muito baixo (0,1);

31 Sendo assim, multiplicando a probabilidade pelo impacto, temos como ranquear e priorizar os riscos. A identificação e qualificação dos riscos geralmente formam uma tabela conforme o quadro abaixo: 31 Risco Probabilidade Impacto Escore Nome do risco Muito alta (0,9) Alta (0,7) Moderada (0,5) Baixa (0,3) Muito alto (0,9) Alto (0,7) Moderado (0,5) Baixo (0,3) Escore = probabilidade X impacto Tabela X: Exemplo de uma tabela de identificação dos riscos Fonte: O autor Restrições e Premissas Restrições e premissas normalmente são criadas no início do projeto, quando não temos informações suficientes para planejar, e também são fontes para a identificação dos riscos. Restrições são limitações impostas internas ou externamente ao projeto, e de acordo com XAVIER (2009, p. 29) podem ser relacionadas com os principais aspectos do gerenciamento do projeto, a saber: Limites de tempo (prazos de conclusão e entrega dos produtos); Limites de recursos (limites de orçamento, de recursos materiais ou humanos); e Outros limites relacionados com as políticas organizações ou legais; Premissas são condições consideradas verdadeiras para o planejamento do projeto. Normalmente implicam em riscos para a execução do projeto, dependendo do seu grau de incerteza. Uma premissa pode ser vista como um pré-requisito para o qual se atribui uma data e uma quantidade específicas. Exemplos (XAVIER, 2009, p. 29): O cliente entregará o terreno limpo no dia xx/xx/xxxx para início das obras; e O departamento de recursos humanos fornecerá dois estagiários, até o dia xx/xx/xxxx, para que sejam utilizados na equipe do projeto Cronograma e custos do projeto Este tópico esclarece a formação de cronograma e custos do projeto. A base desta formação é a EAP que deve estar pronta.

32 Identificar atividades Para identificar as atividades é sugerido que, para cada pacote de trabalho da EAP, os responsáveis técnicos e entendidos do projeto, listem tarefas que, quando realizadas, farão a entrega de todo o trabalho. A decomposição em atividades envolve identificar e documentar as atividades específicas que devem ser realizadas com a finalidade de produzir os pacotes de trabalho constantes na EAP. Nós decompomos os subprodutos em atividades com o objetivo de melhor estimar e controlar os prazos de execução (XAVIER, 2009, p. 54). BARCAUI (2010, p. 25) destaca os seguintes tópicos no que diz respeito ao detalhamento das atividades: Deve ser suficiente para se fazer a estimativa de duração, trabalho e custo da atividade; Deve ser suficiente para se definir as interdependências entre as atividades; Deve ser suficiente para se fazer a alocação da atividade para um recurso; Deve fazer com que a duração das atividades não exceda o período de reporte definido no plano de comunicação; Deve fazer com que a duração das atividades esteja entre 1% e 10% da duração total do projeto; Um exemplo de lista de atividades pode ser visto no capítulo Duração das atividades A estimativa da duração da atividade é um processo de coleta de informações que depende do trabalho a ser realizado e, normalmente, dos recursos a serem alocados. Uma pessoa ou grupo da equipe do projeto que estiver mais familiarizada com a natureza de uma atividade específica deve fazer ou, no mínimo, aprovar a estimativa (XAVIER, 2009, p. 60). As fontes de consulta para a estimativa da duração são (XAVIER, 2009, p. 61): Histórica: é a mais confiável, e se baseia nos dados históricos que a empresa reuniu ou nos dados informados por algum integrante da equipe de projetos com nível de experiência adequada.

33 33 Participativa: é a segunda mais confiável, e provém de alguém que realizou a mesma tarefa no passado, mas não sob as mesmas circunstâncias. Pode-se fazer uso de consultores, convênios de intercâmbio tecnológico ou publicações especializadas. Intuitiva: é proveniente de alguém que realizou tarefas parecidas no passado. Desconhecida: a duração é estabelecida por estimativas, pois não há informações sobre as tarefas. Quando se trata de estimativa da duração das atividades, um fato interessante é que sempre existirá variação entre o planejado e o implementado. BARCAUI (2010, p. 71) destaca os motivos mais significativos: Variação do nível de conhecimento do profissional; Interrupções no expediente: cada vez que uma pessoa é interrompida, ela acaba demorando mais tempo para atingir o nível de produtividade alcançado antes da interrupção; Eventos inesperados; Erros e mal entendidos: algumas vezes inevitavelmente falhamos, provocando retrabalhos ou descarte de atividades; Variações de causa comum: a realidade é que durações variam sem nenhuma razão aparente; Um exemplo de lista de atividades com suas durações pode ser vista no capítulo Sequenciamento de atividades Para XAVIER (2009, p. 56), as atividades devem ser sequenciadas corretamente para suportar o desenvolvimento de um cronograma realístico e alcançável. No sequenciamento uma atividade é sempre predecessora ou sucessora como aponta XAVIER (2009, p.56): Atividade predecessora: é a atividade do cronograma que determina quando a atividade sucessora lógica pode começar ou terminar. Atividade sucessora: é a atividade do cronograma que depende da atividade predecessora, conforme determinado pelo relacionamento lógico entre elas.

34 É fundamental também que sejam considerados, pela equipe técnica do projeto, antecipações (leads) e atrasos (lags) que podem influir na relação lógica entre atividades ou mesmo em sua duração (BARCAUI, 2010, p. 37). XAVIER (2009, p.57) recomenda que o relacionamento entre tarefas seja sempre término-início, ou seja, quando uma tarefa finalizar daí a outra é iniciada. Para BARCAUI (2010, p. 37), a lista de atividades inicialmente obtida por meio da EAP pode ser alterada durante o processo de sequenciamento de atividades Cronograma Para XAVIER (2009, p. 65) o cronograma consiste basicamente em determinar as datas de início e término das atividades do projeto e na aplicação dos seguintes calendários, no sequenciamento das atividades: Calendário do projeto: identifica os períodos em que o projeto está autorizado e afeta todos os recursos (por exemplo, dias úteis). Calendário de recursos: identifica os períodos em que um recurso específico ou uma categoria de recurso poderá trabalhar (por exemplo, colocar como não disponível um período de férias de um membro da equipe). Os calendários informam os dias e horas úteis, como por exemplo, cinco dias por semana e 8 horas úteis por dia. Neles constam feriados como Natal e data de início do projeto. De acordo com XAVIER (2009, p. 73) se for necessário reduzir o término previsto, existem duas técnicas que podem ser empregadas: Compressão (crashing): busca obter a maior compreensão com a adição de recursos. Procura-se obter o mínimo de aumento de custo. Para aplicar em um cronograma devemos: o Computar o caminho crítico; o Estabelecer um objetivo de duração total; o Identificar o tempo e o custo de compreensão para cada atividade no caminho crítico; o Priorizar as atividades do caminho crítico que podem ser comprimidas com menor custo;

35 o Reduzir a atividade de maior prioridade em um período de tempo e comparar com o objetivo de duração; o Verificar o caminho crítico; o Repetir até atingir o tempo desejado; e o Selecionar próxima atividade prioritária e continuar retenção. Caminho rápido (fast tracking): realizar atividades em paralelo que normalmente seriam feitas em sequencia. Frequentemente gera aumento de risco, concentração de recursos e aumento de custo. o O gerente de projeto precisa prestar atenção especial às saídas do planejamento de riscos. É nesta parte que se faz a quantificação de riscos, seu ranking e impactos nos objetivos do projeto e em suas atividades. Por isso, todas as atividades sujeitas a acréscimo de duração como efeito da análise de riscos, devem ter suas durações corrigidas ou readequadas, acrescentando-se as reservas de contingência (para os riscos conhecidos) e a gerencial (para os riscos desconhecidos). o O processo de elaboração do cronograma precisa frequentemente ser repetido antes de ser definir o cronograma do projeto. Os procedimentos de alocação e nivelamento de recursos, assim como o cálculo do caminho crítico, é revisto em função das mudanças impostas pelas restrições de datas e prazos, assim como das respostas aos riscos do projeto Estimativa de custos Segundo BARBOSA (2011, p. 50), a estimativa de custos é uma previsão dos custos dos recursos (por exemplo, mão de obra, equipamentos e materiais) requeridos pelo escopo de uma atividade, pacote de trabalho ou projeto. Portanto, como uma previsão, a estimativa é realizada tendo como base as informações conhecidas num determinado momento, e talvez deve considerar riscos e incertezas. As estimativas de custos são determinadas usando experiência, calculando e prevendo os custos futuros dos recursos. Quando se trata de mão de obra, é possível utilizar as informações das durações das atividades (tópico ) e multiplicar estas durações, convertidas em horas, pelo valor da hora do profissional.

36 36 A estimativa de custos da mão de obra é obtida por intermédio do levantamento das quantidades da mão de obra (homens-horas), das especialidades envolvidas nas diversas fases do ciclo de vida do projeto, bem como da aplicação das tarifas básicas de mão de obra obtidas, por exemplo, a partir da média das tarifas de cada nível de especialização (ex: sênior), de uma categoria (ex: analista de sistemas), da disciplina envolvida (ex: tecnologia da informação). Essas tarifas são, normalmente, obtidas por intermédio de registros em banco de dados históricos de projetos similares anteriores ou da experiência pessoal dos membros da equipe do projeto. Salientamos que utilizamos o relacionamento de custo (CMB = Hh X TAR) (BARBOSA, 2011, p. 67) Comunicação imagem X. O processo de comunicação pode ser representado pelo modelo emissor-receptor na Imagem X: O processo de comunicação Fonte: CHAVES, 2010, p.19. O emissor codifica e emite uma mensagem utilizando um canal de comunicação para o receptor que decodifica esta mensagem. Os canais de comunicação podem ser formais, como s, relatórios e documentos em geral, ou podem ser informais como encontros face a face e mensagens orais. Nesta comunicação acontecem ruídos como falha na interpretação e o feedback é essencial para o emissor saber se sua mensagem foi recebida e compreendida. De acordo com CHAVES (2010, p. 21) na comunicação oral a interação entre as partes é grande, o feedback é imediato e há ótimas possibilidades de se expor, debater e convencer. Mas, geralmente, não existe registro do que foi dito, as emoções podem aflorar e frases podem ser ditas sem que haja reflexão e avaliação prévias. E completa informando que no caso da comunicação escrita ela foi escrita e revisada antes de publicada, pode ser

37 armazenada para consulta posterior e seu conteúdo não varia; é o mesmo para todos os receptores. Mas não há controle total de quem a recebeu, como leu e interpretou e não permite feedback imediato ou consulta em caso de dúvida de interpretação. Perceba que na comunicação informal o feedback é maior e, consequentemente, os ruídos são menores. E que, ao mesmo tempo é importante que haja registros e divulgação por comunicação formal. Por isso, uma boa metodologia deve utilizar ferramentas e técnicas tanto para a comunicação informal, quanto para a formal. Mas atualmente, os processos de gerenciamento de projetos não dão muita atenção para a comunicação informal. Embora canais informais sejam menos enfatizados nos processos de gerenciamento de projetos, muitas vezes seu uso pode contribuir de forma decisiva para o sucesso deles. (CHAVES, 2010, p. 20) Comunicação Informal Os encontros face a face ajudam a reter conhecimentos como PILETTI (2010, p. 154) cita em uma pesquisa que revela a porcentagem de aprendizagem através dos cinco sentidos, sendo: 1% através do gosto; 1,5% através do tato; 3,5% através do olfato; 11% através do ouvido; e 83% através da vista. E retemos: 10% do que lemos; 20% do que escutamos; 30% do que vemos; 50% do que vemos e escutamos; 70% do que ouvimos e logo discutimos; e 90% do que ouvimos e logo realizamos. FIRMINO (2008, p ), sobre a ótica da negociação, cita diversos autores enfatizando o poder da comunicação e principalmente da face a face, destaco alguns: Para Wanderley (1998) os seres humanos captam as informações pelos sentidos, e podem ser classificados em três categorias, que são: visual, auditiva e sinestésica. Para Donaldson (1999) o negociador deve estar atento a linguagem do corpo, pois em uma negociação além da comunicação verbal, há a comunicação não verbal. Gestos, jeito de se vestir, postura, expressões faciais são exemplos de comunicações transmitidas pela linguagem do corpo, porém não acredite em tudo o que você vê, pois a linguagem do corpo aperfeiçoa a comunicação falada, mas não a substitui.

38 Os autores Martinelli e Almeida (2006, p.24) afirmam: Quando negociam, as pessoas mantêm algum tipo de relacionamento, comunicam-se por meio de canais, tornando-a um caso de processo de comunicação interpessoal. Conforme Matos (1985, p.59) procurar enxergar por trás das aparências pode não ser fácil, pelo menos no início, mas é uma necessidade, em termos de boa convivência e ótimas negociações. Os autores Martinelli e Almeida (2006), afirmam que o negociador deve saber ouvir e ainda procurar entender o que não está sendo dito, ou seja, o que está sendo omitido. Deve também observar as expressões faciais, ênfase, entonação e gestos. Conforme Pinto (1992) a comunicação verbal e a comunicação não-verbal caminham lado a lado, porém a expressão corporal pode ser mais produtiva. Para Mills (1993) devemos usar nossa voz, face e os olhos de forma que reforce nossas palavras. O autor faz menção de uma pesquisa realizada por Albert Mehrabian onde relata que a maior parte das informações é transmitida por expressões faciais e pela linguagem não verbal (55%), seguida da voz do locutor, entonação e tom da voz (38%), e por ultimo as palavras que são ditas (7%) Reuniões No caso da comunicação informal, vimos a importância do encontro face a face e, talvez, a reunião seja a técnica mais importante quando se trata de comunicação com relacionamento. As reuniões são essenciais para ampliar o comprometimento de todos os envolvidos. Para CHAVES (2010, p. 89) a reuniões são realizadas com os seguintes objetivos: Integração das pessoas para formar uma equipe de trabalho; Estabelecimento e classificação do que é causa e do que é efeito, ajudando assim a definição mais precisa dos problemas e identificação de caminhos que levam à sua solução; Partida, acompanhamento e finalização de projetos, com a análise de todas as contribuições dadas e avaliação dos resultados;

39 39 E elas são boas quando: Há necessidade de uma resposta rápida de várias pessoas sobre um determinado assunto; Existem problemas ou questões a serem esclarecidas, compartilhadas, expostas ou resolvidas com os demais participantes. Deseja-se envolver o grupo na tomada de decisão, reconciliação de situações de conflito ou na busca de consenso; Deseja-se trocar informações e experiências com o grupo; Pretende-se analisar, avaliar e resolver problemas que envolvam as pessoas de áreas ou empresas distintas; Existem exigências legais a serem implantadas. Mas devemos tomar cuidado para que as reuniões não se transformem em mecanismos de perda de produtividade, desmotivação e falhas na disseminação de informações (CHAVES, 2010, p. 82). O autor também lista as situações que não são convenientes para serem realizadas reuniões. Elas acontecem quando: Outra forma de comunicação se mostrar mais rápida ou adequada, como telefone, ou um papo no corredor; O grupo não houver se preparado adequadamente para a reunião, seja por falta de tempo, atraso na comunicação, escassez de dados ou fatos semelhantes; Não puderem estar presentes as pessoas que realmente tomarão decisões sobre os assuntos a discutir; Existirem posições irreconciliáveis já conhecidas de antemão, o que pode gerar agressividade, hostilidade e ausência de resultados concretos; As decisões já tiverem sido tomadas e o grupo não souber disso ou, simplesmente, quando o assunto for ato trivial que não mereça que se gaste tempo com ele.

40 Mapa de comunicação Os processos de gerenciamento de projetos atuais possuem diversas ferramentas para a comunicação formal, como: EAP, cronograma, matriz de riscos, etc. E todo projeto ainda possui seus próprios documentos técnicos: arquitetura da informação, plantas, design, diagramas técnicos entre outros. Uma boa documentação significa menos discussões e conflitos. Assim, preparar um plano de comunicação compreensível, pode trazer muita economia de tempo, energia e preocupação. Para tanto o PMBOK sugere que seja criado o mapa ou plano de comunicação. A partir da relação das partes interessadas, deve-se produzir um mapa de comunicações, contendo as partes interessadas, o assunto da informação, o documento, o meio, as ações esperadas e o responsável pela emissão (XAVIER, 2009, 78). O exemplo de um mapa da comunicação é apresentado no tópico Equipes BEJARANO (2005, p. 2) cita os estudos de DRUCKER (2001), informando que existem três tipos de equipes, e estas diferem em suas responsabilidades, estrutura e uso: A equipe de beisebol, ou uma equipe cirúrgica, ou uma linha de montagem as pessoas realizam trabalho independente e em série, cada qual em sua posição; A equipe de futebol, ou equipes de projetos, realizam trabalho em paralelo, ou seja, as pessoas trabalham juntas, mas não são interdependentes; A equipe de duplas de tênis, ou um conjunto de jazz existe trabalho interdependente. Como nota o próprio DRUCKER (2001), muitos executivos e a literatura de administração não reconhecem a primeira equipe como sendo uma verdadeira equipe. E muitos estudiosos reconhecem apenas a última como sendo equipe. KATZENBACH e SMITH (2001) estudaram centenas de equipes de trabalho e concluíram que a maioria não tinha uma clara visão dos seus objetivos e/ou como estes poderiam ser alcançados - funcionavam simplesmente como grupos de trabalho, ou seja: grupos onde os membros primariamente dividem informação e melhores práticas ou perspectivas e tomam decisões para ajudar cada indivíduo a melhor desenvolver suas tarefas na área de sua responsabilidade como é o caso nas duas primeiras equipes de Drucker (2001) (BEJARANO, 2005, p. 2).

41 Uma equipe é um grupo de pessoas com aptidões complementares, comprometidas com um objetivo comum, que realizam trabalho interdependente e são coletivamente responsáveis pelos resultados (KATZENBACH e SMITH, 2001). Portanto para um grupo de pessoas formarem equipe é necessário que haja um objetivo comum a ser alcançado. KEEN (2003) indica que antes que uma equipe comece a trabalhar em qualquer tarefa, três fatores básicos devem ser estabelecidos pela equipe: Missão do time - porque o time existe; Objetivos do time - o que o time espera conseguir, e Regras - como o time será administrado e como os objetivos serão alcançados e o progresso medido Equipes de alto desempenho Uma vez um grupo de pessoas tenha superado os obstáculos citados anteriormente para que possa se autodenominar uma equipe, este grupo estará pronto para o desempenho máximo, ou seja, para efetivamente buscar ser uma equipe de alta performance. KIRKMAN AND ROSEN (2000) estudaram 100 equipes e concluíram que diretamente associada ao máximo desempenho das equipes está a sensação de empowerment. Por definição, empowerment significa dar autoridade e motivar membros a agir e tomar decisões. Segundo os pesquisadores, equipes de alta performance têm liberdade para atuar e estabelecer métodos de trabalho e são capazes de executar suas metas, sentem que contribuem com sua existência e possuem um entendimento comum da sua razão de existir (BEJARANO, 2005, p. 6). De acordo com RAJ (2010, p. 72) as empresas que investem em práticas de equipes de projeto de alto desempenho como reorganização do trabalho, envolvimento dos profissionais nos processos decisórios e aperfeiçoamento das habilidades dos trabalhadores obtêm altas recompensas em termos de maior produtividade. O quadro a seguir mostra a diferença entre equipes de projeto tradicionais versus equipes de projeto de alto desempenho: Aspectos Equipes de projeto tradicionais Equipes de projeto de alto desempenho Ênfase no aprendizado O aprendizado é pouco recompensado. O aprendizado é altamente valorizado.

42 42 Concepção do trabalho Papel da gerência Estrutura organizacional Relacionamento com o cliente Flexibilidade Trabalho em equipe Dedicação Remuneração Acesso à informação Equilíbrio sociotécnico As pessoas têm dificuldade para ver como contribuem para o produto ou serviço final e nunca se envolvem na resolução de problemas. Os gerentes atribuem tarefas, analisam o desempenho e decidem quais serão os procedimentos de trabalho sem a contribuição dos funcionários. Existem muitos níveis de gerenciamento e fronteiras nítidas entre gerência e subordinados. As pessoas que trabalham em uma das etapas de uma operação não encaram como seus clientes as que trabalham na etapa seguinte. A equipe demora a adotar novas tecnologias ou a converter tecnologias existentes para novos propósitos. As pessoas olham apenas para si mesmas. Os valores quando existem dizem respeito apenas aos lucros. Só algumas pessoas se sentem pessoalmente responsáveis pelo desempenho da equipe. Todos recebem as mesmas recompensas financeiras, independentemente de seu desempenho. Gerentes e especialistas técnicos retêm informações. O acesso aos sistemas de informação e aos dados é rigidamente controlado. A tecnologia é considerada mais importante que as pessoas. As pessoas veem uma conexão direta entre o que fazem e o produto ou serviço final. A resolução de problemas é parte do trabalho de todos. Os próprios funcionários distribuem as tarefas, analisam o desempenho e decidem quais serão os procedimentos de trabalho adotados. Existem apenas alguns níveis de gerenciamento entre gerência e subordinados. A organização é muito horizontalizada. Todos têm um cliente interno ou externo e buscam constantemente entender e suprir as necessidades do cliente. A equipe explora os progressos tecnológicos e busca encontrar formas inovadoras de utilizar a tecnologia existente. Valorizam-se o trabalho em equipe, a participação, a inovação, a qualidade, tanto quanto os lucros. Todos se sentem pessoalmente responsáveis pelo desempenho geral da equipe. As pessoas são recompensadas de acordo com seu desempenho e/ou da equipe. Gerentes e especialistas técnicos compartilham livremente as informações. Os sistemas de informação permitem que as pessoas compartilhem prontamente as informações. A tecnologia e as pessoas são tratadas como tendo importância igual na equipe. Tabela X: Equipes de projeto tradicionais versus equipes de projeto de alto desempenho

43 43 Fonte: RAJ, 2010, p.71. RAJ (2010, p. 76) diz que normalmente as equipe interfuncionais são os tipos dominantes nas organizações de alto desempenho. As equipes interfuncionais são aquelas que reúnem pessoas por projetos ou processo, com especialistas de muitas disciplinas diferentes fazendo parte da mesma equipe Fases de formação das equipes de alto desempenho De acordo com BEJARANO (2005, p. 6) alguns executivos apostam tanto em suas equipes e no conceito de empowerment, que uma tendência surgiu no mercado americano: a equipe que se autogerencia. Mas para chegar a este nível a equipe passa pelas transições: equipe inicial, equipe de transição, equipe experiente e equipe madura. Elas são exemplificadas na figura abaixo (RAJ, 2010, p. 81): Imagem X: Etapas de transição da equipe Fonte: BOYETT e BOYETT (1999, p ). E em um projeto, a equipe para chegar a ser de alto desempenho, passa pelas fases: formação, confusão/conflito, normatização, desempenho e desintegração. Estas fases estão exemplificadas na figura abaixo (RAJ, 2010, p. 84):

44 44 Imagem X: Fases do desenvolvimento de equipes Fonte: Zannelli et al. (2004, p. 374). Percebe-se que o desempenho da maioria das equipes passa por um declínio antes de alcançar verdadeiros ganhos. Ou seja, as coisas pioram bastante antes de melhorar; a estrada para o alto desempenho é bastante acidentada (RAJ, 2010, p. 84) Líder BEJARANO (2005, p. 3) diz que a tradição Taylorista-Fordista de produção que vigorou no século passado deixou marcas de um modelo administrativo que ainda é preponderante no mercado de trabalho, na figura do chefe que toma decisões individualmente, dando aos seus funcionários pouca ou nenhuma chance de questionar ou discutir processos - elementos essenciais na formação e operação de equipes. Organizações de alto desempenho alteram, permanentemente, os relacionamentos entre gerentes, supervisores e funcionários. Alguns papeis tradicionais, como o de supervisor, desaparecem quase por completo. Outros papéis tradicionais, como o do operário e o do gerente, são inteiramente redefinidos (RAJ, 2010, p. 78).

45 Portanto, para formar equipes é importante que os líderes estejam em um novo paradigma. O quadro abaixo exibe a diferença entre o antigo e o novo paradigma de liderança (CAVALCANTI, 2009, p. 75): Antigo paradigma de liderança Separação entre líder e liderados Sentimento de superioridade do líder Estilos autocrático, laissez-faire ou burocrático de liderança Simples relação visando cumprir os objetivos Líder centrado em objetivos materiais Visão superficial dos objetivos de vida e do trabalho Visão limitada e reducionista aos objetivos imediatos Conflito: procura de culpa Dirige grupos, departamentos, seções, setores isolados de organizações Ênfase em personalidades autoritárias ou obedientes, disciplinadas e energéticas Novo paradigma de liderança Integração entre líder e liderados Sentimento sincero de igualdade entre líder e liderados Estilo participativo de liderança Líder estabelece uma relação evolutiva visando ao crescimento em direção à plena consciência Líder centrado em objetivos e valores superiores Conscientização do sentido profundo da existência e do trabalho Visão holística, abrangente e inclusiva: homem, sociedade e natureza Conflito: procura das causas, oportunidade de aprender e dialogar Incentiva redes de organismos vivos Ênfase em personalidades harmoniosas, porém firmes e lúcidas Tabela X: Antigo versus novo paradigma de liderança Fonte: WEIL, 2000, p Distribuir responsabilidades Verificar se é para fazer ou excluir... Por definição, empowerment significa dar autoridade e motivar membros a agir e tomar decisões (BEJARANO, 2005, p. 6). + PILETTI (2010, p. 154) e 90% do que ouvimos e logo realizamos + página 101 do livro liderança e motivação Qualidade Existem diversas definições de qualidade, VALLE (2012) lista três:

46 46 ASQ - American Society for Quality: A qualidade é o grau até o qual um conjunto de características inerentes satisfaz as necessidades. NBR ISO : De acordo com a NBR ISO Os seguintes conceitos são importantes para a obtenção da qualidade no projeto: - a satisfação das necessidades definidas e implícitas dos clientes e outras partes interessadas é prioritária. PMBOK: O gerenciamento da qualidade do projeto inclui os processos e as atividades da organização executora que determinam as políticas de qualidade, os objetivos e as responsabilidades, de modo que o projeto satisfaça às necessidades para as quais foi empreendido. Entendo que ROSE (2005, p. 6) resume a qualidade como sendo o conjunto das características inerentes de um produto, ou processos, ou do sistema e que estas devem satisfazer as necessidades de clientes e demais partes interessadas. VALLE (2012) resume todas as definições em um simples conceito dizendo que qualidade é: atender as necessidades do cliente. Os tópicos 2.6.1, e a seguir foram retirados do estudo de ROSE (2005, p ) que criou seu próprio método de gerenciamento da qualidade. Este trabalho utiliza tais estudos para a identificação da qualidade Identificando e priorizando os clientes Com a definição de quê qualidade é atender as necessidades do cliente, então a identificação dos clientes é a base para encontrar a qualidade. ROSE (2005, p. 43) diz que os clientes podem ser classificados como externos (o patrocinador, fornecedores e usuários finais), internos (elementos da cadeia de processofornecedor-cliente) e ocultos (aqueles que não estão diretamente envolvidos, mas são impactados com o resultado do projeto). E quem deve identificar estes clientes é a equipe do projeto, e não só identificar como também priorizar, pois a maior parte dos projetos não possuem recursos suficientes para atender a qualidade de todos os clientes. Se todos os clientes são considerados iguais, a equipe de projeto pode ter uma tarefa impossível ao aplicar recursos do projeto, que são limitados, durante a implementação do projeto. A equipe do projeto deve priorizar os clientes (ROSE, 2005, p. 45).

47 De acordo com ROSE (2005, p. 46), depois de identificados os clientes, estes devem ser priorizados utilizando a matriz em forma de L, exemplificada na tabela abaixo. Cliente 1 Cliente 2 Cliente 3 Cliente 4 Cliente 5 Total da linha Valor decimal relativo (total da linha / total geral) Cliente /5 16,2 0,31 Cliente 2 1/5 1/ ,4 0,05 Cliente /10 11,1 0,21 Cliente 4 1/10 1 1/5 5 6,3 0,12 Cliente /5 16,2 0,31 Total Geral 52,2 Tabela X: Priorizando clientes com a Matriz em forma de L Fonte: Adaptado de ROSE, 2005, p. 46. Nesta matriz são utilizadas as seguintes notas: 10: cliente da linha é Muito mais importante que o da coluna 5: cliente da linha é Mais importante que o da coluna 1: cliente da linha é Igualmente importante que o da coluna 1/5: cliente da linha é Menos importante que o da coluna 1/10: cliente da linha é Muito menos importante que o da coluna Após preencher a matriz utilizando as notas acima, é necessário calcular o total da linha que é o somatório das notas de todas as colunas de cada linha. Para o total geral, basta somar todos os total da linha. Feito isso, a tarefa agora é preencher o valor decimal relativo dividindo o total da linha pelo total geral para cada linha. Dessa forma, no exemplo da tabela XX, descobrimos que os cliente 1 e o cliente 5 são os mais importantes e o cliente 2 é o menos importante Identificando e priorizando as necessidades por cliente Voltando com a definição de quê qualidade é atender as necessidades do cliente, então devem ser identificadas também as necessidades dos clientes.

48 De acordo com ROSE (2005, p. 48) os clientes são fontes das necessidades que devem ser atendidas para o sucesso do projeto. E completa: a identificação de necessidades pode exigir pesquisas, entrevistas e análises. O melhor é envolver toda a equipe neste processo. Um velho provérbio japonês informa que "Nenhum de nós é tão inteligente como todos nós." Envolver pessoas diferentes, com diferentes pontos de vista e ideias leva a melhores resultados do que os obtidos por um indivíduo. ROSE (2005, p. 49) informa que é essencial envolver o cliente. É útil analisar os resultados com os clientes e confirmar a compreensão antes de prosseguir. Necessidades identificadas é o momento de priorizá-las. Cada cliente possui suas próprias necessidades e a principal necessidade do principal cliente não quer dizer que seja a principal necessidade a ser atendida pelo projeto. É importante uma priorização individual. Ou seja, é necessário priorizar as necessidades para cada cliente. Tal como acontece com os clientes, nem todas as necessidades são iguais. Um cliente prioritário não é necessariamente a fonte de todas as necessidades de alta prioridade. (ROSE, 2005, p. 50). Portanto, o próximo passo é dar prioridade para as necessidades, comparando-as entre si, a partir da vista de cada cliente. Nós nos colocamos "na pele" de cada cliente na preparação da matriz em forma de L, que compara as necessidades entre si, considerando o ponto de vista de cada cliente. O resultado é um número de matrizes separadas, igual ao número de clientes. Isso pode ser um desafio para a equipe do projeto (ROSE, 2005, p.50). 48 1: Segue uma tabela exemplificando a matriz em forma de L, das necessidades do cliente Cliente 1 Necessidade 1 Necessidade 2 Necessidade 3 Necessidade 4 Necessidade 5 Total da linha Valor decimal relativo (total da linha / total Necessidade /5 16,2 0,31 Necessidade 2 1/5 1/ ,4 0,05 Necessidade /10 11,1 0,21 Necessidade 4 1/10 1 1/5 5 6,3 0,12 Necessidade /5 16,2 0,31 Total Geral 52,2 Tabela X: Priorizando necessidades de clientes com a Matriz em forma de L Fonte: Adaptado de ROSE, 2005, p. 51. geral)

49 49 Nesta matriz são utilizadas as seguintes notas: 10: Para o cliente 1, a necessidade da linha é Muito mais importante que a da coluna 5: Para o cliente 1, a necessidade da linha é Mais importante que a da coluna 1: Para o cliente 1, a necessidade da linha é Igualmente importante que a da coluna 1/5: Para o cliente 1, a necessidade da linha é Menos importante que a da coluna 1/10: Para o cliente 1, a necessidade da linha é Muito menos importante que a da coluna O restante do processo é o mesmo da matriz em forma de L dos clientes, portanto os cálculos para total da linha, total geral e valor decimal relativo podem ser vistos no tópico Dessa forma, no exemplo da tabela XX, descobrimos que, para o cliente 1, as necessidades necessidade 1 e necessidade 5 são as mais importantes e a necessidade 2 é a menos importante. O processo acima deve repetir para cada cliente identificado, que no nosso caso são: cliente 2, cliente 3, cliente 4 e cliente Priorizando as necessidades do projeto Para ROSE (2005, p. 54) o último passo é a parte complicada. Nós combinamos os resultados de prioridade do cliente com os vários resultados de priorização das necessidades para obter uma priorização integrada das necessidades e dos clientes. Construímos esta matriz listando os clientes ao longo do eixo horizontal e as necessidades ao longo do eixo vertical. Assim, é para incluir o valor decimal relativo do cliente em sua coluna. Em seguida, preencher os valores decimais relativos das necessidades em cada linha/coluna, multiplicando o valor decimal relativo do cliente vezes o valor decimal relativo das necessidades para a visão de cada cliente. Segue uma tabela ilustrando a descrição acima, onde N é igual necessidade (VALLE, 2012):

50 50 Tabela X: Priorizando necessidades do projeto Fonte: VALLE, 2012, adaptado de ROSE, 2005, p. 55. Com esta tabela preenchida é possível identificar as principais necessidades do projeto Métodos Ágeis Para FIGUEIREDO (2005, p. 10) os esforços de desenvolvimento atuais, ocorrem, via de regra, em um ambiente altamente instável, tanto em termos de requisitos e necessidades, como em termos de tecnologia e infra-estrutura, e com pressão cada vez maior por entrega rápida, com projetos de poucos meses de duração (PRESSMAN, 2001). Este ambiente instável e complexo deve ser gerenciado por uma metodologia própria.

51 HIGHSMITH (2004) define a gestão ágil de projetos como um conjunto de valores, princípios e práticas, que auxiliam a equipe de projeto a entregar produtos ou serviços de valor, em um ambiente complexo, instável e desafiador. A Gestão Ágil de Projetos está fundamentada nos seguintes valores (AGILE ALLIANCE, 2001): Indivíduos e interações são mais importantes que processos e ferramentas; Software funcionando é mais importante do que documentação detalhada; Colaboração dos clientes é mais importante do que negociação de contratos; Adaptação às mudanças é mais importante do que seguir um plano. FILHO (2005) diz que esses métodos abordam o processo de desenvolvimento de software de forma diferente dos modelos preconizados anteriormente pela Engenharia de Software, que tinham forte ênfase na documentação e nos processos. A principal diferença está na forma como as mudanças são tratadas durante o desenvolvimento do software. Os modelos de processo convencionais adotam a estratégia de previsibilidade. Já os métodos ágeis optam pela adaptabilidade. Os requisitos são levantados aos poucos e o planejamento é contínuo, para que a adaptação às mudanças possa ocorrer. FIGUEIREDO (2005, p. 10) nota que uma importante característica presente em todos os métodos ágeis é o reconhecimento do desenvolvimento de software como um processo empírico (WILLIAMS & COCKBURN, 2003). Processos empíricos são aqueles onde há grande incerteza, pesquisa e descoberta, tornando impraticável a definição completa do projeto num único momento (SCHWABER & BEEDLE, 2002). Os métodos ágeis enfatizam os aspectos humanos do desenvolvimento de software ao invés dos aspectos de Engenharia (LYCETT et al., 2003). Segundo HIGHSMITH (2001), o que existe de novo nos métodos ágeis não são as práticas que eles usam, mas o reconhecimento de que as pessoas são os principais condutores de sucesso do projeto. Outra característica desses métodos é que eles não são centrados nos artefatos. Eles optam por uma documentação apropriada para evitar redundâncias e excessos, para que auxilie efetivamente o desenvolvimento do software (FILHO, 2005). JUNIOR (2011, p. 61) aponta que, na gestão ágil de projetos, além dos valores supracitados, existem seis princípios iterativos de gerenciamento, descritos a seguir (adaptado de HIGHSMITH, 2004): 51

52 52 Entregar valor ao cliente: o projeto deve estar pautado na colaboração entre a equipe de projeto e os consumidores. Empregar entregas iterativas: o projeto deve entregar, sucessivamente, versões preliminares do produto final, que possam ser revisadas e expandidas, a fim de se atingir o resultado almejado. Buscar excelência técnica: projetos que possuem esse quesito têm maiores possibilidade de êxito no mercado. Encorajar a exploração: o gerente de projetos deve saber encorajar sua equipe à experimentação e ao aprendizado, além de manter um senso de direção. Ademais, em um processo de exploração, deve ser perseguida a inovação contínua, adaptabilidade do produto, tempos de entrega reduzidos, capacidade de adaptação do processo e das pessoas e resultados confiáveis. Formar equipes adaptativas: o gerente de projetos deve saber selecionar e formar pessoas que sejam auto-organizáveis e auto-disciplinadas. Simplificar: esse princípio apregoa que se deve utilizar documentação e detalhamentos tão reduzidos quanto possível. Com a finalidade de explicitar melhor o fluxo de trabalho na gestão ágil de projetos, HIGHSMITH (2004) propôs um modelo composto por fases, focado nas entregas (execução) e adaptação: Fase 1: Visão determina a visão e o escopo do produto, a identificação da comunidade do projeto e a definição de como a equipe de projeto trabalhará em conjunto; Fase 2: Especulação nessa fase, há a identificação dos requisitos iniciais do produto, a definição das atividades como uma lista de características do produto, a criação de um plano de entregas, que inclui cronograma e alocação de recursos às características e um planejamento preliminar, seguido por planejamentos específicos a cada iteração; Fase 3: Exploração compreende a entrega de componentes de produtos em curto prazo e que foram planejados na fase anterior; Fase 4: Adaptação revisão dos resultados entregues, da situação atual e do desempenho da equipe e adaptação, conforme o necessário;

53 53 Fase 5: Encerramento o objetivo dessa fase é o aprendizado, ou seja, incorporá-lo ao trabalho da próxima iteração ou transferi-lo para a próxima equipe de projeto. DeMarco (DEMARCO & BOEHM, 2002) argumenta que "os processos direcionados por planejamento (convencional) resultam dos esforços para ensinar organizações a criarem software, enquanto que os métodos ágeis são focados no desenvolvimento das pessoas envolvidas na construção de software". A partir desta visão, essas abordagens passam a ser complementares, ao invés de antagônicas (FIGUEIREDO, 2005, p. 14). FIGUEIREDO (2005, p. 14) alerta que os Métodos Ágeis não são aplicáveis a qualquer domínio (COCKBURN & HIGHSMITH, 2001). A utilização de Métodos Ágeis em equipes desmotivadas ou em organizações centradas em processo, não é aconselhável. Igualmente desaconselhável é a adoção de Métodos Ágeis em projetos onde a colaboração do cliente é limitada (COCKBURN & HIGHSMITH, 2001) Feedback ASFORA (2009, p. 21) diz que a psicologia do aprendizado ensina que o tempo entre uma ação e o correspondente feedback é crítico para o aprendizado. Portanto, um dos mais importantes princípios ágeis é obter feedback, interpretá-lo e colocar o que foi aprendido de volta no processo de desenvolvimento do sistema o mais rapidamente. A compreensão das necessidades dos usuários é um processo de aprendizado contínuo em que os desenvolvedores aprendem sobre os problemas do negócio e os usuários tomam conhecimento das dificuldades e limitações técnicas. Segundo WEINBERG (1971) para atingir essa compreensão dos usuários, um princípio psicológico bem conhecido indica que para maximizar a taxa de aprendizado, a pessoa precisa receber feedback sobre quão bem ou mal ele está indo. ASFORA (2009, p. 21) informa que o feedback é um processo que envolve a priorização de poucas funcionalidades a serem implementadas de cada vez e a simplificação das mesmas na medida do possível. O objetivo se torna apresentar a funcionalidade ao usuário rapidamente, de modo que ele possa, o mais cedo possível, detectar eventuais falhas enquanto ainda é mais barato corrigi-las. A razão básica para estratégias incrementais e iterativas é permitir que os inevitáveis erros das pessoas sejam descobertos relativamente cedo e reparados de forma metódica (COCKBURN, 2002).

54 Participação ativa do cliente Este tópico é composto por trechos retirados do artigo de ASFORA (2009, p ). O planejamento dos requisitos envolve um processo de comunicação de conhecimentos tácitos, o que explica grande parte da dificuldade do desenvolvimento de software (MELO, 2008). Traduzir conhecimento de um contexto para outro, como traduzir qualquer língua, não envolve apenas gramática básica e regras sintáticas, mas também questões de significado e intenção que são contextuais e subjetivas. Segundo EISCHEN (2002), o desenvolvimento de sistemas de software envolve um exercício de traduzir algoritmos existentes sobre o ambiente, organizações ou práticas para a forma digital. Grande parte deste conhecimento sobre o domínio da aplicação é tácito, indefinido, não codificado e desenvolvido ao longo do tempo, frequentemente sem ser explícito até mesmo para os indivíduos que participaram do processo. Além disso, o conhecimento e as práticas organizacionais são dinâmicos evoluindo constantemente e se transformando. Os projetos ágeis apresentam a comunicação como um grande problema que deve ser bem resolvido através do envolvimento direto dos usuários (ou pelo menos um representante dos mesmos) como parte integrante da equipe de desenvolvimento. Na prática, isto significa que o usuário (ou seu representante) está presente no mesmo local onde os desenvolvedores trabalham, possibilitando que eles tenham acesso rápido e direto à um ou mais especialistas no domínio do negócio. Segundo (TELES, 2005), isso ajuda a acelerar o fluxo de informações e permite que a comunicação seja predominantemente feita através de diálogos presenciais. A transferência de conhecimento tácito torna a comunicação muito mais efetiva possibilitando principalmente que o software seja desenvolvido baseado na necessidade real do cliente. Para que um projeto de software seja concluído com sucesso é necessário que se tenha a participação ativa de todas as partes envolvidas. O cliente e a equipe de desenvolvimento têm um papel fundamental nesse contexto. O cliente pode ser envolvido para explicar exatamente o que ele deseja, quais as suas expectativas e necessidades. O cliente também deve participar do projeto e acompanhar o desenvolvimento, mas se a equipe não desenvolver um bom software ou não tiver capacidade técnica para desenvolver da maneira como o cliente deseja, o projeto não terá sucesso. Da mesma forma se a equipe tiver excelentes desenvolvedores que estão empenhados no sucesso do projeto e fazem sempre o que o cliente pede, mas o cliente não está envolvido e não se preocupa ou não tem tempo para esclarecer as dúvidas de

55 negócio, a equipe pode correr o risco de elaborar um software que nunca vai ser utilizado por ninguém porque não se encaixa na necessidade do negócio. Isto significa que cliente e equipe de desenvolvimento são interdependentes e que o sucesso do sistema somente é possível através da cooperação entre as duas partes. Além disso, de acordo com (TELES, 2004), essa proximidade ainda traz como benefício a melhoria na relação de confiança entre as partes envolvidas. Estar fisicamente próximo permite que o cliente perceba mais facilmente os esforços da equipe de desenvolvimento e melhore o relacionamento entre as partes. Além disso, compartilhar os sucessos e fracassos ao longo do projeto também ajuda a elevar a satisfação final do cliente Valor agregado Este tópico é composto por trechos retirados do artigo de ASFORA (2009, p ). Durante a terceira Conferência Internacional sobre Extreme Programming, (Johnson, 2002) apresentou um estudo revelador sobre a utilização das funcionalidades nos projetos que foram pesquisados pelo Standish Group. Os resultados mostram que 45 % das funcionalidades encontradas em um sistema típico jamais são usadas enquanto 19 % raramente são usadas. Na Figura abaixo é possível ver o resultado dessa pesquisa em forma gráfica (ASFORA, 2009). Figura X: Estatística sobre a utilização de funcionalidades Fonte: Johnson, Uma das conclusões do estudo é que cerca de 64% das funcionalidades não necessitariam ter sido desenvolvidas. Em outras palavras, os projetos de software frequentemente investem grande parte dos recursos (tempo, pessoas e dinheiro) em esforços desnecessários.

56 De acordo com (Teles, 2005), em diversos projetos observa-se a ocorrência de três fenômenos que ajudam a esclarecer as razões dos resultados acima: 1) O escopo é fixado no início e alterações no mesmo são evitadas; 2) Os desenvolvedores criam soluções genéricas para facilitar possíveis alterações que possam ocorrer no escopo; 3) Os desenvolvedores produzem funcionalidades adicionais na tentativa de antecipar o que o usuário certamente irá solicitar no futuro. Estes problemas poderiam ser sido evitados com iterações curtas com frequente feedback do usuário, garantindo um escopo reduzido para cada iteração e requisitos priorizados de acordo com o real valor de negócio de cada requisito Priorização das entregas A priorização é a base do processo, responsável por criar sub entregas e assim trazer valor agregado e feedback ao projeto. A priorização de requisitos existe para tentar resolver os conflitos existentes entre as necessidades dos usuários sem, todavia impactar na satisfação dos objetivos de cada usuário. 51): Dentre as principais vantagens de priorizar os requisitos incluem (ASFORA, 2009, p. Evita escolhas entre alguns objetivos conflitantes como qualidade, custo, e timeto-market. Priorização dos recursos baseado na importância para o objetivo do projeto Priorização pela técnica Kano O texto abaixo é formado por trechos retirados do artigo de ASFORA (2009, p ). O processo proposto abaixo de priorização de requisitos para projetos foi baseado na técnica Kano, e foi desenvolvida por Noriaki Kano em 1984 (COHN, 2005). De acordo com (INFO ESCOLA, 2009), Kano é uma técnica para o desenvolvimento ou melhoria de produtos baseado na caracterização das necessidades do cliente, sejam elas explicitamente verbalizadas ou não.

57 57 em: A pesquisa realizada por Kano mostra uma forma de priorizar as partes dos produtos 1) Indispensável ou mandatório; 2) Importantes ou linear; 3) Desejáveis. De acordo com (COHN, 2005), essa divisão é voltada para priorizar as características que deixam o cliente mais satisfeito. Por exemplo: Um requisito indispensável de um hotel pode ser a limpeza, a cama, o banheiro, uma mesa. Uma vez satisfeita às necessidades do hóspede com o banheiro não importa se ele tem prateleira ou não. Com isso, os requisitos indispensáveis devem estar presentes, embora não estejam diretamente ligados com a satisfação do usuário, uma vez que se ele for feito de uma forma melhor não proporciona um acréscimo em satisfação. Os requisitos importantes podem ser descritos da seguinte forma: são diretamente relacionados com a satisfação e aumentam de forma progressiva. Exemplo, se um hotel tem ar condicionado, televisão, banheira, ou seja, quanto maior a quantidade desses itens maior a satisfação. Já os requisitos desejáveis fornecem uma grande satisfação quando estão presentes, frequentemente adicionando um preço ao produto para satisfazer tais requisitos. O ponto principal é que o fato de uma característica não estar presente pode não trazer nenhuma decepção ao cliente muito menos diminuir a satisfação com o produto final. Frequentemente, estas são chamadas de necessidades desconhecidas, pois os clientes não sabem que precisam delas até possuí-las. A Figura abaixo mostra a representação dos níveis de satisfação. Figura X: Modelo Kano de satisfação do cliente Fonte: Cohn, 2005.

58 Como utilizar Kano O texto abaixo é formado por trechos retirados do artigo de ASFORA (2009, p ). As perguntas são formadas de uma pergunta positiva e outra negativa indicando como o cliente irá se sentir caso o referido requisito ou estória esteja presente na próxima entrega ou não estivesse finalizado qual seria a sua reação. A combinação das respostas às perguntas funcionais e disfuncionais gera um resultado para cada requisito, que determina a importância do mesmo. As perguntas seriam formadas da seguinte forma: Como você se sentiria caso o Requisito X, estivesse no próximo release? Como você se sentiria caso o Requisito X, NÃO estivesse no próximo release? As opções de resposta apresentadas são (Cohn, 2005): 1. Seria melhor dessa forma 2. Eu esperava dessa forma 3. Estou neutro 4. Eu consigo aceitar dessa forma 5. Não gosto dessa forma Assim sendo, aplicando as duas perguntas acima para cada requisito ou grupo de requisitos o quadro abaixo é utilizado como referência para identificar a prioridade, ou categoria de prioridade: Figura X: Respostas às perguntas funcionais, disfuncionais e resultados para cada combinação. Fonte: ASFORA, 2009, p. 64.

59 As categorias mandatório/indispensável, importante e desejado já foram explicadas. Já o questionável se refere quando o cliente coloca respostas antagônicas o que pode significar que ele ou não entendeu as perguntas ou ele não está respondendo com veracidade. O reverso significa que se aquele requisito for desenvolvido poderá trazer, ao invés de satisfação, uma rejeição ao software ou à determinada funcionalidade. Finalmente, o indiferente como é visto no quadro acima é o que está presente na maior quantidade de combinações e é utilizado quando o usuário demonstra que não tem necessidade real para esta funcionalidade, ou seja, tanto faz que ela seja satisfeita ou não. De acordo com COHN (2005), o ideal para aplicar a técnica de Kano seria de ter de 20 a 30 usuários respondendo a pesquisa Kanban O kanban é um subsistema do sistema Toyota de produção (STP) usado para controlar os estoques em processo, a produção e o suprimento de componentes e, em determinados casos, de matérias-primas. Definido como um sistema de coordenação de ordens de produção e compra (SCO) por Fernandes e Godinho Filho (2007), o sistema kanban controla a produção dos produtos necessários, na quantidade e no momento necessário (JUNIOR, 2008). JUNIOR (2008) diz que a tradução literal da palavra kanban é anotação visível, ou sinal. O sistema kanban é conhecido por empregar determinados cartões para informar a necessidade de entregar e/ou produzir certa quantidade de peças ou matérias-primas. O Kanban consiste em um espaço representado por cartões que apresenta as etapas do fluxo de trabalho com as atividades e atribuições dos membros da equipe (MONTEIRO, 2012). MONTEIRO (2012) diz que o Kanban é um sistema puxado, ou seja, uma atividade só é puxada de uma etapa para outra respeitando a quantidade de trabalho que a equipe suporta. O quadro mostra os gargalos (pontos de sobrecarga de atividades) no processo, o que diminui o tempo normalmente despendido para identificação do problema. A fim de solucionar esses gargalos, Kanban limita o WIP (Work-In-Progress) para quando o número de atividades envolvidas em uma determinada etapa for igual ao número limite estipulado. Desta forma, atividades da etapa anterior ficarão bloqueadas impedindo a continuação do fluxo. É importante salientar que o Kanban não descreve as práticas a serem usadas no

60 desenvolvimento, ele apenas fornece a visibilidade necessária para o acompanhamento do projeto (ANDERSON, 2011) Tipos de contratos Os tipos mais comuns de contratos são: Por administração ou custo reembolsável; Preço unitário; e Preço fixo, preço global ou preço fechado (XAVIER, 2009, p.124). Por administração ou custo reembolsável: o Os custos do fornecedor são reembolsados pelo contratante, que recebe um valor fixo ou percentual pela sua administração; o Normalmente o escopo do trabalho ainda não foi definido; o O risco é maior para o contratante, pois os custos finais são desconhecidos; e o Tipo de contrato normalmente utilizado quando o contratante não tem o escopo definido e/ou quer ter agilidade na conclusão do projeto. Preço unitário: o O preço é feito em uma base unitária (por hora, por dia, por metro etc.); o Possui elementos de um contrato a preço fixo (no preço unitário) e de um contrato de custo reembolsável (na não definição da quantidade, fazendo com que o custo total seja desconhecido); o O risco do contratante e do contratado em relação aos custos é médio, comparado aos outros tipos; e o Normalmente o escopo do trabalho não está totalmente definido quando da contratação. Preço fixo, preço global ou preço fechado: o Forma mais comum de contrato; o Preço acordado para todo o escopo; o Apropriado quando o contratante pode descrever o escopo do trabalho; o O contratante tem menor risco; o Todo risco de custos excedentes fica com o fornecedor;

61 o Embora assuma todo o risco, o fornecedor é compensado pelo grande potencial de lucro; e o O fornecedor se preocupa em fechar o escopo do trabalho antes da assinatura do contrato. 61 Figura X: Tipos de contrato sob a ótica do contratante Fonte: RIBEIRO, 2012, p. 32. Figura X: Comparação de risco entre os tipos de contratos Fonte: XAVIER, 2012, p Considerações Finais Este capítulo mostrou o que é o gerenciamento de projetos assim como um resumo das principais práticas de gerenciamento de projeto do PMBOK Guide (2008), consagradas pelo mercado. Seguiu com a tradicional gestão de riscos e com a moderna ferramenta da qualidade que facilita o encontro das principais necessidades dos clientes. Foi visto a importância da comunicação e da comunicação informal que é tão pouco comentada. E mostrou o poder da formação de equipes de alto desempenho assim como a mudança de paradigma na liderança. Por fim, foram apontados os princípios e valores dos métodos ágeis e a sua grande contribuição para o gerenciamento dos projetos.

62 No próximo capítulo de Metodologia Científica será abordada a metodologia científica utilizada neste trabalho METODOLOGIA CIENTÍFICA 3.1. Considerações Iniciais Este capítulo define o tipo de metodologia científica utilizada para resolver a questão proposta no início do trabalho Metodologia Definição de Metodologia do glossário do Guia PMBOK (PMI, 2004b, p. 369): Metodologia / Methodology. Um sistema de práticas, técnicas, procedimentos e regras usadas pelas pessoas que trabalham em uma disciplina. Definições de método e metodologia segundo a enciclopédia digital Wikipédia (CURI, 2009, p. 40): Método (do Grego methodos, met' hodos que significa, literalmente, "caminho para chegar a um fim"). Em ciência, em geral, o método científico é constituído por uma série de passos codificados que se têm de tomar, de forma mais ou menos esquemática para atingir um determinado objetivo científico (...). A Metodologia é o estudo dos métodos. Ou então as etapas a seguir num determinado processo. Tem como finalidade captar e analisar as características dos vários métodos disponíveis, avaliar suas capacidades, potencialidades, limitações ou distorções e criticar os pressupostos ou as implicações de sua utilização. Este trabalho utiliza dois paradigmas, o paradigma qualitativo, onde a pesquisa apoiouse nas metodologias de mercado, no guia de melhores práticas em gerenciamento de projetos do PMI, nos estudos em aulas e livros advindos do curso de gestão de projetos da FGV e nas pesquisas realizadas em artigos referentes a métodos ágeis. E também utiliza o paradigma prático, com a aplicação de tais conhecimentos em um ambiente corporativo real, no qual recebeu feedbacks e moldes via análise de resultado e opiniões.

63 A metodologia de pesquisa adotada neste trabalho está baseada na taxionomia de VERGARA (2004), que qualifica a pesquisa quanto aos fins e quanto aos meios (CURI, 2009, p. 41). Quanto aos meios: Pesquisa Bibliográfica: estudo sobre o tema apresentado por outros autores, por isso será feita uma revisão bibliográfica, ou seja, pesquisa em livrarias, instituições de ensino e na Internet, dos livros, artigos, dissertações e teses em português e inglês. Pesquisa prática: Quanto aos fins: Exploratória: o gerenciamento de projetos é um assunto largamente difundido, mas no que tange a participação ativa da equipe e também das partes interessadas em um cenário de custo fixo existe ainda pouca literatura a respeito, por isso, pretende-se explorar um pouco mais esse assunto; Metodológica: pretende-se com esse trabalho construir uma metodologia efetiva de gerenciamento de projetos de preço fixo com formação de equipes de alto desempenho e foco nas necessidades das partes interessadas Considerações Finais Este capítulo destacou que este trabalho é de cunho qualitativo e prático, cujo meio será a pesquisa bibliográfica e a aplicação real e tem como fins explorar o assunto de gerenciamento de projetos de preço fixo com participação ativa da equipe e das partes interessadas com foco na qualidade e propor uma nova metodologia para esses projetos. No próximo capítulo de Análise de Dados é detalhada a metodologia proposta, inicialmente mostrando-a o quão completa é a partir de um comparativo com os processos do Guia PMBOK e também das metodologias ágeis. Posteriormente explorando-a demonstrando seu ciclo de vida e seus atores e finaliza aprofundando em seus processos, descrevendo detalhadamente cada um e permitindo entendimento e aplicação nas corporações.

64 64 4. ANÁLISE DOS DADOS 4.1. Considerações Iniciais Este capítulo detalha a metodologia efetiva de gerenciamento de projetos de preço fixo com formação de equipes de alto desempenho e foco nas necessidades das partes interessadas, tendo como base o referencial teórico e prático pesquisado, como o PMBOK Guide, os métodos ágeis, a gestão de equipes, a qualidade, a comunicação e o kanban Comparativo com o PMBOK Guide O PMBOK Guide é o principal guia das melhores práticas em gerência de projetos, por isso, foram utilizados os mesmos nomes dos grupos de processos e das áreas de conhecimento de sua 4ª edição, dessa forma a maturidade do PMI foi aproveitada e a comunicação com os leitores simplificada. A proposta é que esta metodologia possibilite que toda a gestão de um projeto seja realizada e para isto ela tem que ser completa. Segue um comparativo dos processos PMBOK Guide demostrando como o MethodNula completa todas as áreas de conhecimento. PMBOK 4a. Edição MethodNula Gerenciamento de Integração do projeto 4.1 Desenvolver o termo de abertura do projeto I.1 - Elaborar a proposta 4.2 Desenvolver o plano de gerenciamento do projeto 4.3 Orientar e gerenciar a execução do projeto P.9 - Organizar responsabilidades e plano do projeto E.3 - Equipe gerenciar a execução E.2 - Equipe formar o Kanban com entregas semanais 4.4 Monitorar e gerenciar o trabalho do projeto C.1 - Controlar o andamento do projeto E.2 - Equipe formar o Kanban com entregas semanais 4.5 Realizar o controle integrado de mudanças C.2 - Equipe gerenciar mudanças 4.6 Encerrar o projeto ou a fase F.1 - Apresentar partes do produto F.2 - Encerrar projeto Gerenciamento de Escopo do projeto 5.1 Coletar requisitos I.2 - Identificar as partes interessadas P.10 - Stakeholders participarem do planejamento F.1 - Apresentar partes do produto 5.2 Definir escopo I.3 - Definir o escopo e o mapa do produto 5.3 Criar EAP (Estrutura Analítica do Projeto) I.4 - Criar mapa do projeto (EAP)

65 65 PMBOK 4a. Edição 5.4 Verificar escopo 5.5 Controlar Escopo MethodNula P.10 - Stakeholders participarem do planejamento E.1 - Criar protótipo e design do produto F.1 - Apresentar partes do produto C.1 - Controlar o andamento do projeto C.2 - Equipe gerenciar mudanças E.3 - Equipe gerenciar a execução Gerenciamento de Tempo do projeto 6.1 Definir atividades I.5 - Estimar tempo 6.2 Sequenciar atividades I.5 - Estimar tempo 6.3 Estimar recursos da atividade I.5 - Estimar tempo 6.4 Estimar duração da atividade I.5 - Estimar tempo 6.5 Desenvolver o cronograma P.4 - Criar cronograma 6.6 Controlar o cronograma C.1 - Controlar o andamento do projeto C.2 - Equipe gerenciar mudanças E.3 - Equipe gerenciar a execução Gerenciamento de Custos do projeto 7.1 Estimar custos I.6 - Estimar custos 7.2 Determinar orçamento I.6 - Estimar custos 7.3 Controlar custos C.1 - Controlar o andamento do projeto Gerenciamento da Qualidade do projeto 8.1 Planejar qualidade P.6 - Equipe planejar a qualidade 8.2 Realizar garantia da qualidade E.3 - Equipe gerenciar a execução E.5 - Garantir a qualidade P.9 - Organizar responsabilidades e plano do projeto 8.3 Realizar controle da garantia da qualidade C.1 - Controlar o andamento do projeto C.3 - Equipe controlar a qualidade e os riscos 9.1 Desenvolver o plano de recursos humanos Gerenciamento de Recursos Humanos do projeto P.2 - Analisar múltiplos projetos e definir equipe P.3 - Planejar aquisições e adquirir 9.2 Controlar ou mobilizar a equipe do projeto P.2 - Analisar múltiplos projetos e definir equipe 9.3 Desenvolver a equipe do projeto 9.4 Gerenciar a equipe do projeto P.5 - Formar equipe, líder e negociador E.6 - Desenvolver a equipe do projeto C.4 - Gerenciar as partes interessadas e a equipe do projeto Gerenciamento das Comunicações do projeto 10.1 Identificar as partes interessadas I.2 - Identificar as partes interessadas 10.2 Planejar as comunicações P.8 - Planejar a comunicação P.9 - Organizar responsabilidades e plano do projeto 10.3 Distribuir informações E.4 - Distribuir as informações 10.4 Gerenciar as expectativas das partes interessadas 10.5 Relatar desempenho C.4 - Gerenciar as partes interessadas e a equipe do projeto E.1 - Criar protótipo e design do produto F.1 - Apresentar partes do produto F.4 - Encerrar estratégico do projeto C.1 - Controlar o andamento do projeto E.3 - Equipe gerenciar a execução

66 66 PMBOK 4a. Edição Gerenciamento de Riscos do projeto MethodNula 11.1 Planejar o gerenciamento de riscos P.7 - Equipe planejar os riscos 11.2 Identificar riscos P.7 - Equipe planejar os riscos 11.3 Realizar análise qualitativa de riscos P.7 - Equipe planejar os riscos 11.4 Realizar análise quantitativa de riscos Não há 11.5 Planejar respostas aos riscos 11.6 Monitorar e controlar riscos P.7 - Equipe planejar os riscos P.9 - Organizar responsabilidades e plano do projeto C.1 - Controlar o andamento do projeto C.3 - Equipe controlar a qualidade e os riscos Gerenciamento de Aquisições do projeto 12.1 Planejar aquisições P.3 - Planejar aquisições e adquirir 12.2 Conduzir aquisições C.5 - Administrar aquisições 12.3 Administrar aquisições C.5 - Administrar aquisições 12.4 Encerrar aquisições F.3 - Encerrar aquisições Tabela X: Tabela comparativa dos processos PMBOK com o MethodNula Fonte: o autor. Note que é uma metodologia mais simples já que possui um total de 31 processos contra os 42 processos do PMBOK Comparativo com os métodos ágeis Os métodos ágeis ficaram conhecidos por se adaptarem rapidamente a mudanças, por alinharem constantemente a comunicação com as partes interessadas e também por criar equipes de alto desempenho, estes dois últimos estando no título deste trabalho, portanto, a nova metodologia proposta possui características similares com os métodos ágeis. FILHO (2005) fez um importante estudo que descreveu dez padrões organizacionais e de processo e os comparou com os métodos ágeis. Este trabalho aproveita o estudo de FILHO comparando os métodos ágeis com o MethodNula, apesar deste estudo utilizar a ótica de desenvolvimento de sistemas, a MethodNula é genérica podendo ser aplicada em outras áreas de atuação. Segue abaixo a tabela comparativa que serve também como texto explicativo sobre como é feita a execução do projeto. Nome Implied Requirement Linguagem de padrões Project Management Pattern Language, Episodes. Resumo O problema é definir as necessidades do cliente de forma significativa para os desenvolvedores. Portanto, selecione e nomeie partes de funcionalidade e crie uma lista com essas partes. Método ágil XP, Scrum MethodNula? Existe. No faseamento, no mapa do produto, no agrupamento do cronograma e no kanban

67 67 Nome Work Queue Size the Organization Engage Customers Developing in Pairs Few Roles Stand up Meeting Developer Controls Process Patron Role Linguagem de padrões Project Management Pattern Language, Episodes. Piecemeal Growth Pattern Language Piecemeal Growth Pattern Language Piecemeal Growth Pattern Language Organizational Style Pattern Language People and Code Pattern Language Project Management Pattern Language Piecemeal Growth Pattern Language Resumo O problema é conceder tempo para realizar tudo. Portanto, crie um cronograma que é simplesmente uma lista priorizada de trabalho. Use a lista do Implied Requirement como ponto de partida e ordene-a, em uma ordem de implementação, de modo que favoreça os itens mais urgentes ou de maior prioridade. Quando a equipe de desenvolvimento é muito grande, raramente os projetos são entregues dentro do prazo e orçamento previstos. Se a equipe é muito grande a comunicação pode falhar. Se a equipe é pequena, a produtividade vai diminuir. Por isso, escolha aproximadamente dez pessoas para compor a equipe de desenvolvimento e evite acrescentar indivíduos depois de iniciado o desenvolvimento. Se você quer gerenciar um processo de desenvolvimento incremental que acomode informações fornecidas pelo cliente, junte o cliente aos desenvolvedores e arquitetos, não somente ao QA (Quality Assurance) ou marketing. Se você quer melhorar a efetividade individual dos desenvolvedores, coloque os desenvolvedores para trabalharem em pares. As pessoas em um projeto devem se comunicar para o projeto progredir. Mas, o custo indireto dessa comunicação pode impedir o verdadeiro progresso que ela deveria facilitar. Portanto, tente manter o número de papéis da organização abaixo de dezesseis. Em tempos de mudanças rápidas é essencial que todos os membros da organização recebam as mesmas informações. Portanto, realize reuniões diárias, de aproximadamente quinze minutos, com toda a equipe, para trocar informações críticas sobre o projeto. Como os Desenvolvedores contribuem diretamente no desenvolvimento dos artefatos visíveis para o usuário final, faça do desenvolvedor o ponto foco de informação do processo. É importante dar continuidade ao projeto. Mas, um controle centralizado pode dificultar o progresso. Assim, eleja um Patrono para o projeto, para que as barreiras que impedem o progresso do projeto sejam removidas. Método ágil XP, Scrum XP, Scrum XP, Scrum XP XP, Scrum XP, Scrum XP, Scrum Scrum MethodNula? Existe. Na formação do kanban e na priorização junto com as partes interessadas. Existe. Este número de pessoas é o recomendável por etapas ou fases do projeto. Existe. Principalmente nos processos P.10 - Stakeholders participarem do planejamento e F.1 - Apresentar partes do produto. Não declarado. Ficando a decisão para a equipe em execução ou no planejamento. Existe. A princípio, as responsabilidades estão distribuídas em dez papéis. Existe. Principalmente nos processos E.5 - Garantir a qualidade e C.1 - Controlar o andamento do projeto. Existe. Com a participação ativa da equipe nas decisões mais importantes. Existe. Tornando um membro da equipe como líder. Processo P.5 -Formar equipe, líder e negociador

68 Nome Surrogate Customer Fire Walls Linguagem de padrões Piecemeal Growth Pattern Language Piecemeal Growth Pattern Language Resumo É importante trocar idéias com os clientes. Mas se o cliente não estiver disponível, crie um papel de Substituto do Cliente no projeto, com alguém que irá tentar pensar como o cliente. É importante proteger os desenvolvedores de outras pessoas envolvidas no projeto, que não participam do desenvolvimento, mas sentem necessidade de ajudar por meio de comentários ou críticas. Portanto, crie um cargo de gerente, que protege os desenvolvedores de interações com Método ágil XP Scrum MethodNula? 68 Existe. Tornando um membro da equipe um negociador. Processo P.5 -Formar equipe, líder e negociador Existe. Momentos para interações com a equipe, existência de líder e do gerente do projeto. cargos externos. Tabela X: Padrões organizacionais e de processo e métodos ágeis comparando com o MethodNula Fonte: adaptado de FILHO, 2005, p Comparativo com gestão de pessoas Continuando com os estudos de FILHO (2005), segue um comparativo que serve também como um texto explicativo, sobre como a nova metodologia proposta propõem o gerenciamento de pessoas. Nome Community of Trust Day Care Linguagem de padrões Project Management Pattern Language Project Management Pattern Language Gate Keeper Piecemeal Growth Pattern Language Self Selecting Team Unity of Purpose Piecemeal Growth Pattern Language Piecemeal Growth Pattern Language Resumo O relacionamento social tem um impacto significante na efetividade da equipe. Faça suas atividades de forma que demonstre confiança explicitamente. As ações devem ser visíveis e evidentes, para que as pessoas da equipe confiem umas nas outras. Os especialistas estão gastando todo seu tempo ensinado os principiantes. Assim, coloque um especialista como responsável por todos os principiantes e deixe os outros especialistas desenvolverem o sistema. O fluxo da informação é importante, mas o excesso de comunicação pode prejudicar o projeto. Portanto, nomeie uma pessoa, o Porteiro, que cuida do fluxo de informações externas úteis para os envolvidos no projeto. O Porteiro também pode passar informações para pessoas importantes de fora do projeto. Não existe um critério perfeito para selecionar membros de uma equipe, mas os interesses dos indivíduos não devem ser ignorados. Assim, crie equipes entusiasmadas com as pessoas escolhendo sua própria equipe. Muitos projetos têm um inicio difícil com as pessoas se esforçando para trabalharem juntas. Frequentemente, as pessoas têm idéias diferentes de como o produto final deveria ser. Assim, o líder do projeto deve expor para todos membros da equipe uma visão comum e propósito geral. MethodNula? Existe. Principalmente com o quadro kanban e com os relatórios de acompanhamento. Existe. Com a criação do líder no processo P.5 - Formar equipe, líder e negociador Existe. Tornando um membro da equipe um negociador. Processo P.5 - Formar equipe, líder e negociador Existe. No processo P.5 - Formar equipe, líder e negociador Existe. No processo P.5 - Formar equipe, líder e negociador

69 Nome Linguagem de padrões Matron Role Piecemeal Growth Pattern Language Compensate Success Organization Follows Location Shaping Circulation Realms The Water Cooler Piecemeal Growth Pattern Language Organizational Style Pattern Language Organizational Style Pattern Language Organizational Style Pattern Language Resumo Algumas atividades são necessárias para manter a equipe prosseguindo no trabalho técnico. Por isso, assegure que a equipe contenha uma Mãe, que vai tratar dos assuntos sociais e pessoais necessários para manter a equipe unida. Estabeleça recompensas para os indivíduos que contribuem para o sucesso do projeto. Todo a equipe deve receber recompensas parecidas, para evitar desmotivação individual. Assim, a organização fica mais focada na satisfação do cliente e no sucesso do sistema. Se for necessário distribuir o trabalho geograficamente, a comunicação pode ser prejudicada, mas você pode limitar os danos se o trabalho puder ser dividido. Assim, organize o trabalho de forma que os grupos de pessoas que trabalham juntas estejam no mesmo local. A comunicação entre os participantes do projeto é fundamental para o sucesso e não se pode esperar que a comunicação aconteça espontaneamente. Portanto, crie estruturas na organização ou no espaço de trabalho que apóiem a comunicação. As organizações precisam evitar o isolamento das equipes. Em ambientes amplos é difícil apoiar a freqüente interação entre as equipes. Promova estruturas sociais que não estão relacionadas ao local de trabalho, onde as pessoas podem se encontrar, tanto para pausa quanto para comunicação. MethodNula? 69 Existe. O líder e o gerente do projeto, que devem seguir os conceitos de liderança conectiva. Não está nos processos. É recomendável que a recompensa esteja ligada as necessidades dos clientes. Existe. O projeto é dividido em fases e etapas, no mínimo se, ultrapassar dois meses ou se tiver mais de dez membros. Existe. Os processos definem regras de apoio a comunicação. Não está nos processos. É recomendável que exista. Tabela X: Padrões organizacionais e de processo comparando com o MethodNula Fonte: adaptado de FILHO, 2005, p Introdução quanto a metodologia Os grupos de processos iniciação, planejamento, execução, controle e encerramento do PMBOK Guide foram mantidas, as principais alterações se concentram nos processos visando garantir efetividade nos projetos buscando gerar equipes de alto desempenho e atingir as necessidades das partes interessadas. A imagem abaixo é uma visão macro da metodologia, mostrando os grupos de processos, os momentos de inicia-los e os seus processos. Um diferencial deste modelo é a definição do momento (ciclo de vida), ou seja, quando cada grupo de processo será iniciado.

70 70 Imagem X: Grupos de processos, momentos e processos do MethodNula Fonte: o autor. O grupo de processo de iniciação é constituído por processos base para a formação de preço e prazo do produto caracterizando a metodologia como preço fixo. Nota-se que este momento chama-se pré-venda, orçamentação ou prospecção e se faz simples com poucos processos induzindo ao baixo custo de manutenção. Isso permite que uma empresa realize diversos orçamentos sem grandes despesas. É importante notar que os grupos de processos execução, controle e encerramento são iniciados diversas vezes como em um ciclo, ou seja, em no máximo de dois em dois meses, podendo ser semanal, os processos são reiniciados e partes do produto são apresentadas para as partes interessadas. Este ciclo afeta o planejamento forçando que alguns processos deste grupo sejam realizados novamente. Dessa forma, podemos dizer que esta nova metodologia é realizada em espiral, onde o produto vai sendo formado aos poucos a alinhando as expectativas das partes interessadas. Somando a isto, as partes interessadas participam do planejamento em P.10 Stakeholders participarem do planejamento.

71 Os processos promovem a participação do time do projeto nas principais decisões, e pode ser visto que vários destes possuem a equipe em seu nome demonstrando o tamanho de sua responsabilidade, acrescido a isto, o P.5 Formar Equipe, Líder e Negociador tem por objetivo formar uma visão de time unificada, um objetivo e a distribuição de responsabilidades (que é feita nos processos sequentes) sugerindo a formação de uma equipe de alto desempenho. Sendo este o foco, o planejamento não visa detalhar as funcionalidades do produto e sim criar visão e caminhos certos para se alcançar o sucesso, e também visa encontrar os caminhos errados por onde a equipe não deve passar. Para a leitura dos tópicos posteriores é importante manter a imagem acima sempre em vista Escopo da metodologia O escopo da nova metodologia se limita ás fronteiras e camadas de um projeto, ou seja, inicia realizando um planejamento de prazo, custo e escopo e se encerra com a entrega do produto e seus aceites. Dessa forma, ela não prevê fases anteriores como análise de negócios e investimentos e nem fases posteriores como divulgação e operacionalização do produto. Ela pode ser utilizada em qualquer área de atuação como campanhas publicitárias, desenvolvimento de softwares, pesquisas e desenvolvimento, jurídico, laboratórios, departamentos de empresas, construção civil entre outros, e de qualquer tamanho. Para tanto, basta complementá-la com uma camada técnica, ou seja, processos que dizem respeito a área em questão. Por ter maior envolvimento da equipe e das partes interessadas ela não é aconselhada em cenários com a maior parte da execução sendo feita a distância ou com pouco acesso ao patrocinador. Apesar de não limitar o tamanho da equipe, ela apregoa que quando há equipes acima de dez pessoas o projeto seja dividido em fases que tenha no máximo dez pessoas cada. Quanto ao tamanho, se o projeto for muito extenso, ele deve ser dividido em fases de no máximo dois meses cada. A proposta contempla equipes compostas por pessoas atuando de forma compartilhada em vários projetos simultâneos.

72 Momentos A nova metodologia divide o projeto em quatro momentos: 1. Pré-venda: é o momento onde os projetos estão sendo propostos e orçados. 2. Projeto aprovado: inicia quando o patrocinador aprova a proposta, e é realizado um maior planejamento. 3. Execução: quando a equipe desenvolve o projeto e realiza o controle dele. 4. Encerramento: quando a equipe finaliza uma parte do projeto ou o todo. Cada momento possui, no mínimo, um tipo de reunião principal, fortalecendo o envolvimento da equipe, distribuindo informações com qualidade, utilizando conhecimento de todos e reduzindo a necessidade de documentação com o uso da comunicação informal. A seguir são apresentados os momentos em uma visão mais superficial e resumida Pré-venda Note que no momento um que é pré-venda, já são feitas a EAP, o levantamento das atividades, a estimativa de tempo e a estimativa de custos formando a proposta. Isso acontece por causa do modelo preço fixo que obriga as prestadoras de serviço a já informarem prazo e custo na proposta. Ao mesmo tempo é um formato enxuto, não sendo o planejamento mais completo possível, e nem gastando demasiados recursos e custos da empresa que, provavelmente, faz muitos orçamentos gratuitamente por ano e muitos não fecham.

73 73 Imagem X: Atores quem executam os processos do momento um, pré-venda. Fonte: o autor. Há a reunião de trabalho, onde a equipe de planejamento, responsável pela prospecção, em conjunto com a equipe do orçamento, responsáveis pelo conhecimento técnico, irão trabalhar nos processos: identificar as partes interessadas, definir o escopo e o mapa do produto, criar mapa do projeto (EAP), estimar tempo, estimar custos e elaborar a proposta. A ideia é que as tarefas sejam distribuídas de uma forma que os projetos em andamento não sejam prejudicados. O gerente de projetos, pouco interage neste momento, tendo a responsabilidade de indicar quem esteja mais apto ou disponível para trabalhar no orçamento Planejamento O projeto sendo aprovado (o que pode demorar a acontecer) é iniciado o momento do planejamento. Agora a empresa deve disponibilizar mais tempo no planejamento e inclusive alterar as informações da pré-venda, que é o momento um, se considerar necessário.

74 74 Imagem X: Atores quem executam os processos do momento dois, projeto aprovado. Fonte: o autor. Logo no início o gerente de projetos realiza os seguintes processos: classificar projeto, analisar múltiplos projetos e definir equipe, planejar aquisições e adquirir e criar cronograma. Para tanto, ele conta com conselhos e suporte da equipe do orçamento, equipe do planejamento e o controlador, que possuem conhecimentos prévios do projeto. Feito este trabalho inicial, ou partes destes processos, é(são) marcada(s) reunião(ões) interna(s) com a equipe. O papel do gerente de projetos é mostrar para a equipe como proceder com os processos, informando as regras e opinando pouco nas decisões. Na primeira reunião são apresentados e discutidos todos os documentos gerados no momento um - pré-venda e o grupo de pessoas deve se aceitar como equipe, criar uma visão única do projeto e escolher quem será o líder, o negociador e o controlador da qualidade. Nesta ou, se necessário, em outra(s) reunião(ões), são identificados objetivos e regras estratégicas para a condução do projeto, que pretendem desnuviar, abrir caminhos e provocar entendimentos que permitam a todos que alcancem as necessidades das partes interessadas, tudo isto com a execução dos seguintes processos, pela própria equipe: equipe planejar a qualidade, equipe planejar os riscos e planejar a comunicação.

75 O planejamento desta nova metodologia não detalha como o trabalho será feito e sim levanta uma visão de onde pretende chegar a partir do planejamento da qualidade, onde não pode haver falhas no planejamento de riscos e como alinhar as expectativas das partes interessadas com o planejamento da comunicação. Os resultados gerados pelos processos acima são agrupados, revisados, organizados, registrados e publicados no processo organizar responsabilidades e plano do projeto. O próximo passo é realizar a reunião de Start que conta com a participação do patrocinador, equipe do projeto e demais stakeholders, todos em um mesmo local. Nesta reunião são apresentados e discutidos todos os documentos gerados até o momento, assim torna transparente e nivela expectativas a partir da apresentação do processo (regras), da qualidade (objetivo), dos riscos, do escopo e do prazo. O ideal é que os participantes tomem decisões e debatam fortalecendo o entendimento, mas também o relacionamento, e criando motivação e sinergia de time. Geralmente o patrocinador é o mais indicado a trazer sentimento ao time. Nesta reunião, e durante todo o projeto, o gerente de projetos deve manter a seguinte regra: o patrocinador é o responsável pelo negócio e a equipe é responsável pela técnica. O gerente não toma grandes decisões, talvez ajudando com opiniões, mas com foco em garantir que esta regra seja cumprida. As reuniões tendem a gerar adaptações, correções e melhorias nas estimativas já prontas e estas devem ser revisadas e os impactos devidamente calculados e aprovados Execução Agora que o relacionamento está fortalecido e transparente e os conhecimentos tácitos e explícitos devidamente alinhados e aprovados, a equipe está preparada para iniciar a execução do projeto. Mesmo sendo um momento de execução são utilizadas ferramentas de planejamento, mas em um movimento cíclico e mais informal.

76 76 Imagem X: Atores quem executam os processos do momento três, execução. Fonte: o autor. É executado o processo criar protótipo e design do produto demonstrando razoavelmente e visualmente como ficará o produto, ou a parte dele que é o escopo da fase atual do projeto. Este processo, não obrigatório, visa alinhar a comunicação de todos, apresentado uma visão mais próxima do resultado final e permitindo que modificações sejam feitas no projeto com um menor impacto principalmente em custos e prazos. A reunião para a formação do kanban pode ser o primeiro ou segundo passo da execução, ou seja, em determinados projetos torna-se importante que este processo seja executado antes do processo anterior. Nela são planejadas as entregas cíclicas (exemplo: semanais) e formado o quadro do kanban (a fazer, fazendo, feito, validado) como ferramenta de gestão a vista. Esta reunião é realizada pela equipe e pelo líder e o gerente de projetos se limita em manter as regras fazendo o processo funcionar. A cada início e entrega de grupos de tarefas o time executa o processo equipe gerenciar a execução onde coleta progresso e lembra escopo, custo, prazo, qualidade e riscos estes também são lembrados semanalmente no processo controlar o andamento do projeto que é responsável pela reunião de acompanhamento, por alinhar a todos sobre o status atual, reorganizar a execução, detectar problemas e gerar relatórios de acompanhamento internos e externos. Estes são realizados por incentivo e suporte do líder.

77 Os processos distribuir as informações e equipe gerenciar mudanças, apesar de distribuir responsabilidades com todos os membros da equipe do projeto como gerenciar pedidos de mudanças e estarem atentos ao plano de ação e ao planejamento da comunicação, ficam mais centrados no negociador que deve preocupar com o planejamento das negociações, o armazenamento das informações, promover reuniões, garantir a qualidade das informações e procurar autorizações de mudanças e de mudanças emergenciais. O gerenciamento das partes interessadas e da equipe do projeto são responsabilidades do gerente de projeto e do negociador que devem estar atentos aos conflitos e as soluções destes. O controle dos riscos e da qualidade também possui distribuição de responsabilidade para todo o time, mas em geral as tarefas são centradas no líder e no controlador da qualidade que comparam o planejado com o realizado. Por fim, o gerente de projeto é responsável por executar os processos: desenvolver a equipe do projeto, administrar aquisições e garantir a qualidade. Este último promovendo reuniões de auditoria feitas pelo gerente de projetos e reuniões periódica de curto prazo (como exemplo diária) com a equipe do projeto que detecta os impedimentos e se atualizam do todo. Como o planejamento desta nova metodologia não detalha como o trabalho será feito, é na execução que o como fazer é levantado. 77

78 Encerramento Imagem X: Atores que executam os processos do momento quatro, encerramento. Fonte: o autor. O destaque do momento de encerramento é o processo apresentar partes do produto que acontece, no tempo máximo, de dois em dois meses. Neste processo são alinhadas as expectativas, o caminho trilhado é moldado para atender as necessidades das partes interessadas, problemas não se repetem para outras partes do produto, o produto começa a tomar forma, é criada transparência entre equipe interna e externa, os riscos, qualidade, prioridades, atividades, comunicação e entre outros são revistos e realinhados. Assim que o projeto é encerrado é realizada entre outras a reunião de lições aprendidas que fortalecem e fixam o conhecimento do que está certo e ajudam a eliminar o que está errado no processo. Toda a equipe do projeto participa destas duas reuniões e também do encerrar estratégico do projeto que pretende gerar ideias de negócios que podem ser, entre outras, novos outros projetos e também em levantar quais resultados, principalmente técnicos, o projeto resulta para a comunidade que trazem evoluções na sociedade e também fortalece a marca da empresa. O gerente de projeto mantém a regra e é responsável pelo processo encerrar aquisições.

79 Entendendo a nova metodologia Partes interessadas participarem do processo Equipe participar do processo Responsabilidades Artefatos e entregas 4.4. Processos O autor considera a parte mais importante deste trabalho este tópico que descreve detalhadamente todos os processos, permitindo que os conhecimentos levantados e o objetivo sugerido da metodologia sejam aplicados em ambiente corporativo. Os processos estão no formato ETVS (Entrada Tarefa Verificação Saída), representado na tabela abaixo: << Nome do Processo >> <<Descrição do processo>> Entrada <<Entrada 1>> <<Descrição da entrada>> Como fazer? <<Nome tarefa 1>> <<Descrição da tarefa 1>> <<Nome tarefa 2>> <<Descrição da tarefa 2>> <<Papeis>> <<Papeis>> Verificação

80 80 <<Nome verificação 1>> <<Descrição da tarefa 1>> <<Nome verificação 2>> <<Descrição da tarefa 2>> <<Papeis>> <<Papeis>> Resultados <<Entrada 1>> <<Descrição da entrada>> De acordo com a Wikipédia, processo é uma sequência de tarefas (ou atividades) que ao serem executadas transformam insumos (informações) em um resultado com valor agregado. São os processos que organizam e gerenciam a equipe do projeto (XAVIER, 2009, p. 8) Iniciação O grupo de processos de iniciação consiste nos processos realizados para definir um novo projeto ou uma nova fase de um projeto existente, obtendo autorização para tal. Nos processos de iniciação, o escopo inicial é definido e os recursos financeiros iniciais são comprometidos (PMI, 2008, p. 44). O grupo de processos de iniciação organizam os processos conforme demonstrado na imagem abaixo.

81 81 Imagem X: Processos da iniciação. Fonte: o autor. Os tópicos abaixo descrevem detalhadamente cada um destes processos Elaborar a proposta Elaborar a proposta (I.1)

82 Elaborar a proposta (I.1) É o processo de desenvolvimento de um documento que formalmente autoriza um projeto e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas. Similar ao PMBOK: Desenvolver o termo de abertura do projeto Entrada Solicitação de proposta Pedido feito por um, ou mais, cliente(s) solicitando a proposta de projeto. Ela deve conter, no mínimo, as seguintes informações: Necessidade de negócio que o produto do projeto deverá satisfazer; e Descrição e requisitos do projeto e do(s) produto(s) que ele deverá produzir. Como fazer? Elaborar o planejamento Equipe de planejamento Formular um objetivo para o projeto e executar os outros processos da iniciação para formar o escopo, estimar a duração e os custos. Desenvolver a proposta Equipe de planejamento Utilizar todas as informações adquiridas no elaborar o planejamento. Levantar as restrições e premissas do produto e do projeto, estas geralmente são detectadas pelos participantes do processo. Consolidar todas as informações em um único documento. Verificação Revisar proposta Equipe de planejamento A equipe de planejamento é responsável por consolidar as informações e revisar toda a proposta. Validar proposta Equipe do cliente A equipe do cliente é a responsável por validar a proposta solicitando alterações ou aprovando o projeto. Normalmente o escopo, custo e prazo são as informações que mais causam revisões e alterações na proposta. Resultados Proposta Documento descrevendo o objetivo, a necessidade do projeto, o escopo, prazo estimado, orçamento, restrições e premissas.

83 Identificar as partes interessadas Identificar as partes interessadas (I.2) O conceito das partes interessadas, ou stakeholders, foi abordado em Este processo tem como objetivo gerar uma relação dos principais stakeholders do projeto, que contenha informações relevantes sobre eles. Essa relação, além de ser útil para a equipe de planejamento, também servirá de referência para outros processos e participantes do projeto. O documento gerado neste processo será utilizado para registrar todos os requisitos (desejos, necessidades e expectativas) das partes interessadas no decorrer do projeto. Similar ao PMBOK: Identificar as partes interessadas Entrada Informações de contatos Informações de contatos adquiridas em conversas, s, reuniões, projetos anteriores e etc. Solicitação de proposta Visto em Como fazer? Levantar as partes interessadas Equipe de planejamento ou Negociador Relacionar as pessoas e organizações que direta ou indiretamente atuarão, ou serão afetadas, positivamente ou negativamente, pelo projeto, com suas respectivas funções e responsabilidades, bem como as suas expectativas e interesses no resultado dos projetos. Segundo CHAVES (2009, p. 33), para a análise dos stakeholders devemos: Identificar o universo dos envolvidos; Analisar a importância e influência dos envolvidos; Analisar o interesse dos envolvidos críticos; Enquadrar no gráfico abaixo Grade de poder e interesse ; e Definir as estratégias de ação; As partes interessadas devem ser registradas em um documento semelhante ao abaixo: Nome Poder alto, médio, baixo SH exemplo Interesse alto, baixo (+ ou -) médio, Requisitos o que já foi dito Alto Alto (-) Ex: tem sonho de participar do desenvolvimento do módulo X e quer um projeto simples e compacto Gráfico X: Exemplo da tabela de identificação de stakeholders, parte 1 Fonte: o autor Na iniciação o levantamento das partes interessadas é criado e mantido pela Equipe do Planejamento. Assim que a proposta do projeto for aprovada, então esta responsabilidade passa a ser do negociador. Geralmente esta tabela é ampliada com os campos abaixo que devem ser sigilosos (pessoal e privado): Papel no projeto Outras características Classificação Estratégia o que fazer Validador Difícil para se Bloqueador Envolvê-lo nas reuniões da equipe, reportar a sua

84 84 trabalhar Identificar as partes interessadas (I.2) pessoa, sempre incluir informações solicitadas por ele Gráfico X: Continuação da tabela de identificação de stakeholders, informações sigilosas Fonte: o autor Normalmente a equipe do planejamento não preenche esta continuação, mas se preencher, estas informações não podem ser passada para os outros membros. Gráfico X: Grade de poder e interesse Fonte: adaptado do PMI (2008, p. 209) Verificação Manutenção das partes interessadas Negociador Este documento é confidencial e as várias informações contidas nele não podem ser repassadas para outras pessoas do time, portanto a verificação fica sendo responsabilidade de quem o está mantendo. Resultados Relação das partes interessadas do projeto O resultado desse processo é uma relação completa com os nomes, funções, responsabilidades, interesses e demais dados relevantes das partes interessadas no projeto Definir o escopo e o mapa do produto Definir o escopo e o mapa do produto (I.3)

85 Definir o escopo e o mapa do produto (I.3) O conceito do escopo foi abordado em e também em Este processo transforma os desejos, necessidades e expectativas do cliente em uma visão do produto e do quê será criado. Para tanto, ele resulta principalmente em uma representação gráfica para o escopo do produto, que é basicamente um organograma demonstrando como, de acordo com o planejado, o produto ficará. Esta ferramenta é base para a construção do projeto, pois ela demonstra o quê pretendemos alcançar, e é essencial para a comunicação com as partes interessadas. Entrada Solicitação de proposta Visto em Relação das partes interessadas Visto em O levantamento dos contatos junto com seus dos desejos, necessidade e expectativas. Como fazer? Levantar requisitos Equipe de planejamento É provável que os produtos e serviços que devem ser entregues, e suas correspondentes especificações já foram listados pelo cliente. Quando não está claro, é necessária a realização de reuniões, entrevistas, ou outra forma de contato, para tirar as dúvidas. A lista dos requisitos é salva na relação das partes interessadas. Planejar escopo Equipe de planejamento Pesquisar soluções existentes e identificar novas soluções por meio de reuniões ou pesquisas. Pesquisar soluções existentes significa fazer o levantamento de uma lista de projetos de referência, que ajudam na comunicação com o cliente e com a equipe, no sentido de saberem qual linha prosseguir. A reunião de novas soluções pode ser feitas por um grupo de pessoas multidisciplinares, utilizando a técnica de brainstorming. Definir escopo e estratégia Equipe de planejamento O planejamento do escopo pode gerar diversas ideias impraticáveis, ou ideias para vendas futuras. Portanto é importante separar o que será feito agora do que será feito depois. Todas as informações levantadas e selecionadas até agora são consolidadas em um único documento. Elaborar o mapa do produto Equipe de planejamento O mapa do produto representa a estrutura "estática" do produto a ser gerado no projeto, apresentando suas áreas e seções de forma hierárquica, em formato de árvore ou como um mapa mental. A ideia é converter em visual o que está descrito como a declaração do escopo, facilitando na comunicação e entendimento entre as partes. Nele vê-se facilmente o que está dentro ou fora do escopo. O mapa divide o produto em partes e cada parte do produto se converte em um grupo de partes do produto. Por exemplo: no produto apartamento, temos as partes: cozinha, sala, quarto e banheiro. Depois, para cada parte é descrito suas sub-parte mais significativas.

86 Definir o escopo e o mapa do produto (I.3) Por exemplo: na parte quarto, temos as sub-parte: piso, parede, rodapé, armário embutido, iluminação. E para cada sub-parte, há uma elucidação do que se pretende fazer. Por exemplo: na sub-parte piso, ter um descritivo dizendo o piso será de madeira em forma de taco. Repare que estes exemplos não cita nada do projeto, como encanamento, mão de obra e fiação, sendo uma visão de futuro, feita de forma rápida e barata, de como o produto será entregue. Exemplo de um mapa do produto, de um pequeno projeto, em um ambiente de desenvolvimento de sistemas Web: Imagem X: Exemplo de um mapa do produto Fonte: autor Verificação Validar escopo internamente Equipe do orçamento A equipe responsável por fazer o orçamento validará se as informações levantadas e registradas permitem o prosseguimento com o trabalho. Validar escopo Equipe do cliente O cliente valida se o escopo, o que vai ser produzido, está conforme sua ideia para o negócio. Esta validação é opcional, e recomendada para planejamento mais complexo. Os processos à frente possuem validações com o cliente. Revisar mapa do produto Equipe do orçamento A equipe do orçamento revisará se o mapa do produto está completo e correto tecnicamente. Validar mapa do produto Equipe do cliente A equipe do cliente valida se o mapa do produto corresponde a suas expectativas de negócios. Pode ser que este alinhamento de expectativa com a equipe do cliente gere vários retrabalhos no mapa do produto, o que é bom, já que este é um momento onde as alterações no escopo são de baixo custo. Inclusive, o ideal é provocar discussões por meio de reuniões, detalhamento e propostas de alterações para cada parte e subparte do mapa. Resultados

87 87 Relação das partes interessadas atualizada Definir o escopo e o mapa do produto (I.3) Este processo envolve muita interação com o cliente gerando mais percepções dos desejos, necessidades e expectativas destes. Declaração do escopo Um documento com os dados levantados tendo como informações obrigatórias: principais entregas do projeto, lista de restrições e premissas detectadas, responsabilidades encontradas do cliente e da equipe, ideias a serem aplicadas no futuro e uma lista do quê não está incluído no escopo do projeto Criar mapa do projeto (EAP) O conceito da EAP foi abordado em Criar mapa do projeto (EAP) (I.4) Este processo cria uma representação gráfica para o escopo do projeto, que é basicamente um organograma demonstrando como o produto será produzido e lançado. O objetivo é criar uma base para todo o planejamento do projeto e também melhorar a comunicação com a equipe e demais stakeholders. Entrada Declaração do escopo Visto em Solicitação de proposta Visto em Relação das partes interessadas Visto em Mapa do produto Visto em

88 Criar mapa do projeto (EAP) (I.4) Como fazer? Elaborar o mapa do projeto (EAP) Equipe do orçamento Para criar uma EAP ou aqui chamada de mapa de projeto, é importante estudar os documentos de entrada como mapa do produto, declaração de escopo, solicitação de proposta e requisitos presentes na relação das partes interessadas, a fim de encontrar tarefas a serem realizadas que entreguem (deliverables) partes do produto e do escopo planejado. Se tiver que testar um produto antes de entregar, este teste deve estar na EAP, se tiver que contratar alguém, a contratação deve estar na EAP. Cada caixa da EAP é um pacote com diversas atividades e uma entrega. Cada entrega representa um pedaço do produto, o que é chamado de subproduto ou de deliverables. Seguem os cinco passos para a elaboração de uma EAP, utilizando a técnica top-down - de cima para baixo (adaptado dos sete passos de XAVIER, 2009, p ): 1. Colocar no primeiro nível da EAP o nome do projeto; 2. Colocar no segundo nível as fases que estabelecem o ciclo de vida do projeto; a. O conceito de ciclo de vida foi abordado em b. Exemplo: planejamento, execução, finalização e divulgação; 3. Acrescentar os deliverables ou subprodutos referentes ao escopo do cliente; a. Encontrar nos documentos de entrada os principais produtos e serviços; b. Caso o número de subprodutos seja grande, eles devem ser agrupados em um terceiro nível. c. Exemplo de subprodutos: em execução os subprodutos (deliverables) podem ser ilustração, criação de conteúdo, arquitetura da informação, desenvolvimento da interação com usuário, desenvolvimento do módulo um do sistema. 4. Para cada deliverable colocado na EAP, verificar se as estimativas de custo e tempo, assim como a identificação de riscos e a atribuição de responsabilidade para a execução do mesmo, podem ser desenvolvidas neste nível de detalhe. Se a resposta for negativa, decompor os elementos da EAP, subdividindo-o em componentes menores, mais manejáveis. a. O ideal é que cada subproduto dure no mínimo quatro horas e no máximo quarenta horas, permitindo um maior controle das entregas do projeto e melhorando a exatidão das estimativas; b. Deve haver uma definição clara de responsabilidades para cada subproduto; 5. Rever e refinar a EAP até que o planejamento do projeto possa ser completado; Um exemplo de um mapa do projeto ou EAP, de um projeto em sistemas Web, pode ser visto a seguir.

89 Criar mapa do projeto (EAP) (I.4) Imagem X: Exemplo de um mapa do projeto Fonte: autor Os elementos nos níveis mais baixos da EAP (aqueles que não foram decompostos) são denominados pacotes de trabalho, sendo a base lógica para a definição das atividades, designação de responsabilidades, estimativa de custos e planejamento de riscos. Neste exemplo sobre a ótica de sistema Web, destaquei de laranja, os subprodutos que normalmente o mapa do produto pode ser utilizado como requisito. Observa-se, portanto, que uma grande parte do trabalho de um projeto não é descoberto somente por analisar superficialmente o resultado do produto, e sim, precisa de pessoal técnico qualificado e de muita reflexão para detectar tais trabalhos. Verificação Revisar mapa do projeto (EAP) Equipe do planejamento A equipe do orçamento valida se o mapa do projeto está completo e correto tecnicamente, a equipe do planejamento verifica se está completo e correto em nível de negócios. Geralmente são as equipes de orçamento e de planejamento que causam vários retrabalhos no mapa do projeto. E é essencial que isto ocorra já que todo o restante do projeto depende da qualidade da EAP. Conscientizar mapa do projeto (EAP) Equipe do cliente Para a equipe do cliente é importante que entenda como é o processo de construção, onde este processo lhe causará impactos ou ações internas e quais são suas responsabilidades. E ele precisa aprovar isso.

90 Criar mapa do projeto (EAP) (I.4) Resultados Relação das partes interessadas atualizada Declaração do escopo atualizada Mapa do projeto O mapa do projeto pode gerar mais dúvidas e interações com o cliente, portanto os novos desejos, necessidades e expectativas devem ser registrados. O mapa do projeto é uma ferramenta do escopo e, seu desenvolvimento, tende a mudar o que estava previsto até o momento como: as principais entregas do projeto, lista de restrições e premissas detectadas, responsabilidades encontradas do cliente e da equipe e uma lista do quê não estão incluídos no escopo do projeto. É o documento do mapa do projeto disponibilizado em um formato de arquivo comum, no qual as partes interessadas consigam acessar Estimar tempo Estimar tempo (I.5) O conceito de estimar tempo foi fundamentado em e Este processo será realizado pelas seguintes tarefas: identificar as atividades, prever os recursos das atividades, as dependências dos grupos de atividades ou atividades e estimar as durações das atividades. Entrada Declaração do escopo Visto em Solicitação de proposta Visto em Mapa do projeto (EAP) Visto em Mapa do produto Visto em Como fazer? Identificar as atividades Equipe do orçamento Fundamentado em Cada subparte do mapa do produto deve gerar uma lista de atividades, e a soma das atividades devem gerar o produto. Acrescido a isso, um projeto possui diversas atividades ao entorno do produto e é necessário também listar todas as atividades de cada subproduto da EAP (como demonstrado no ). Geralmente o pessoal especializado é capaz de descobrir todas as tarefas que compõem os subprodutos da EAP e do mapa do produto. Recomendo que inicie identificando as atividades que compõem o mapa do produto, depois marque na EAP os subprodutos que já tiveram suas atividades descobertas. Depois, o trabalho é identificar as atividades dos outros subprodutos da EAP.

91 91 Prever os recursos das atividades Estimar tempo (I.5) Equipe do orçamento Em geral, cada atividade é realizada por um recurso humano e pode utilizar recurso material ou equipamento. Portanto, é obrigatório informar a pessoa ou, mais comum o tipo do profissional (exemplo: desenvolvedor sênior), para cada atividade identificada. Como este é um processo de inicialização, o ideal é que seja marcado no cronograma o tipo do profissional, já que é raro saber quem formará a equipe do projeto. Esta metodologia não permite ter mais de um recurso humano por atividade, se for necessário, então se deve criar outra atividade com um nome similar. Se o projeto utilizar mais de dez pessoas simultaneamente, etapas ou fases do projeto devem ser criadas, prevendo que formem grupos de no máximo dez pessoas. Identificar as dependências das atividades Equipe do orçamento Fundamentado em As tarefas precisam ser sequenciadas para gerar noção de prazo e de alocação de recursos. Para isso, cada subproduto do mapa do projeto (EAP) deve ter suas atividades sequenciadas. O relacionamento sempre será do tipo término-início, ou seja, o sequenciamento deve levar em consideração que uma atividade começa assim que outra finaliza. Se recursos distintos foram utilizados em um mesmo subproduto da EAP, então é provável que as atividades daquele deliverable sejam feitas em paralelo. Estimar as durações das atividades Equipe do orçamento Fundamentado em A estimativa das durações geralmente é feita por especialistas que, para cada atividade identificada, informa o número de horas ou dias que acredita gastar. Se houver dados históricos, o recomendado é utilizar o tempo realizado, de atividades similares, de projetos anteriores, melhorando a qualidade da estimativa. Se algum especialista já realizou tarefas similares no passado, o ideal seja que ele faça as estimativas. Se o projeto for muito complexo ou de alto risco pode utilizar a técnica Delphi que consiste no trabalho de três especialistas, cada um fazendo sua própria estimativa, e depois reunindo em um debate sobre cada atividade, onde no fim todos tem que estar de acordo com uma única duração. Para a estimativa das durações das atividades é muito importante que se criem premissas ao projeto, com isto os especialistas ficam mais seguros e tranquilos para prever o tempo. É importante ressaltar que a estimativa da duração, visto no tópico , nunca será real, ou seja, igual ao realizado (BARCAUI, 2010, p. 71), esta informação de ser levada em conta na comunicação com o cliente e na previsão de entrega de todo o projeto. No exemplo abaixo vemos uma lista com as atividades identificadas, recursos previstos, dependências identificadas e durações estimadas.

92 Estimar tempo (I.5) Imagem X: Exemplo de todas as ferramentas do processo estimar tempo aplicadas Fonte: autor Todas as ferramentas do estimar tempo impactam uma sobre as outras, portanto as atividades identificadas são alteradas pelos recursos previstos, ou pelas dependências identificadas ou pelas durações estimadas e vice-versa. Verificação Validar o estimar tempo Equipe do orçamento Por ter um aspecto técnico, a própria equipe do orçamento é responsável por validar se as atividades foram identificadas, sequenciadas, estimadas e se os recursos foram aplicados corretamente. Validar duração para o negócio Equipe do planejamento A equipe do planejamento validará se a duração está de acordo ou não com o negócio. Caso não esteja, o processo estimar tempo pode ser revisto utilizando técnicas de paralelismo ou compressão (adicionar recursos), informando que tais técnicas aumentam significativamente o risco do projeto (XAVIER, 2009, p. 73). Resultados Declaração do escopo atualizada Mapa do projeto atualizado Estimativa de tempo Lista de recursos do projeto O estimar tempo cria informações importantes para a declaração do escopo, como: escopo dos subprodutos da EAP e das subpartes do mapa do produto, as principais entregas do projeto, lista de restrições e premissas detectadas e responsabilidades encontradas do cliente. As decisões do estimar tempo alteram o planejamento de como o projeto será produzido. Um documento com a lista de atividades sequenciadas, com duração prevista e com recursos aplicados. Este documento informará quantos dias úteis é previsto para a duração do projeto. Lista dos tipos de recursos que o projeto irá empregar.

93 Estimar custos Estimar custos (I.6) O conceito de estimar custos foi fundamentado em e É o processo que envolve desenvolver uma estimativa dos custos dos recursos necessários para a implementação das atividades do projeto. Entrada Declaração do escopo Visto em Solicitação de proposta Visto em Mapa do projeto (EAP) Visto em Estimativa de tempo Visto em Lista de recursos do projeto Custo unitário dos recursos Visto em Os custos unitários dos recursos humanos, materiais e equipamentos. Como fazer? Calcular os custos das atividades e do projeto Equipe do orçamento Fundamentado em Custo é a quantidade de capital necessária para se realizarem as atividades do projeto. Portanto, a base do calculo dos custos de um projeto deve ser a soma dos custos de suas atividades. E o custo de uma atividade é calculado como a soma dos custos dos recursos envolvidos na atividade com os custos indiretos da atividade, como supervisão e etc. Custo direto da atividade são: custos de mão de obra, custo de materiais e suprimentos e custo de serviços contratados. Custo indireto da atividade, ou custos administrativos, são: custos de gerenciamento, custos de sistemas utilizados, custos de inflação ou juros. Cada atividade gasta um tempo de um recurso humano e, também um tempo de um recurso material. O ideal é que o custo deste recurso humano e material seja convertido em horas, daí o processo é calculado da seguinte forma: multiplicar o valor hora do recurso pelas horas da atividade. Para esta metodologia, recomenda-se que os custos administrativos também sejam convertidos em horas, e estes custos horas sejam acrescidos ao custo hora do recurso humano. Por exemplo, se um recurso humano tiver um custo hora de 32 reais e o custo hora administrativo for de 12 reais, então o custo hora do recurso humano passa a ser = 44 reais. Se assim for, os custos administrativos devem ser distribuídos pelos diversos recursos humanos da empresa. Acrescido aos custos das atividades, o custo total de um projeto ainda contemplam a reservas de contingências para contemplar os eventos de riscos que inevitavelmente virão. É recomendado que este valor não seja

94 Estimar custos (I.6) aleatório e sim embasado em uma lista de riscos. Algumas empresas e projetos possuem ainda uma taxa de buffer que é um fundo reserva para o desconhecido. A formação dos custos deve contemplar o lucro. Analisar premissas, restrições e riscos Equipe do orçamento Até o momento foram várias as premissas e restrições (ver ) levantadas por toda a equipe. O ideal é que alguns riscos também tenham sidos levantados. Estas informações devem ser convertidas em atividades com durações, ou somente em custos diretamente. Verificação Validar o estimar custo Equipe do orçamento A equipe de orçamento deve revisar e corrigir os custos até que estes fiquem o mais justo para ambas as partes, para o cliente não pagar pelo que não vai receber e para a empresa não levar prejuízo, seja pelos riscos, pela baixa qualidade da estimativa ou pelo erro nos cálculos de custos. Os projetos de custo fixo trazem muito mais riscos para os fornecedores do quê para os clientes. Validar custo para o negócio Equipe do planejamento A equipe do planejamento validará se o custo está de acordo ou não com o negócio. Caso não esteja, pode ser necessário revisar todo o planejamento feito até o momento, removendo ou simplificando atividades. Muitas vezes, a simples atribuição de premissas ao projeto torna a estimativa mais segura e os especialistas ficam mais tranquilos para prever o tempo. Resultados Mapa do projeto atualizado Mapa do escopo atualizado Estimativa de tempo atualizada Lista de recursos do projeto atualizada Orçamento As decisões do estimar custo alteram o planejamento de como o projeto será produzido. As decisões do estimar custo podem alterar o resultado final do produto. O estimar custo interage constantemente com o estimar tempo atualizando-o. O estimar custo altera o planejamento de como utilizar os recursos. Orçamento do projeto é o documento com as estimativas dos custos globais aos itens individuais de trabalho com a finalidade de estabelecer um baseline de custo para medir o desempenho do projeto. Este orçamento deve levar em consideração a necessidade de financiamento, seja ela parcial e/ou periódica. Pode ser apresentado com a necessidade financeira total, diária, semanal, mensal, trimestral, semestral, anual etc (XAVIER, 2009, p. 76).

95 Planejamento O Grupo de Processos de Planejamento consiste nos processos realizados para estabelecer o escopo total do esforço, definir e refinar os objetivos e desenvolver o curso de ação necessário para alcançar esses objetivos. Os processos de planejamento desenvolvem o plano de gerenciamento e os documentos do projeto que serão usados para executá-lo. A natureza multidimensional do gerenciamento de projetos cria loops de feedback periódicos para análise adicional. À medida que mais informações ou características do projeto são coletadas e entendidas, pode ser necessário um planejamento adicional. Mudanças significativas ocorridas ao longo do ciclo de vida do projeto acionam uma necessidade de revisitar um ou mais dos processos de planejamento e possivelmente, alguns dos processos de iniciação. Este detalhamento progressivo do plano de gerenciamento do projeto com frequência é denominado planejamento por ondas sucessivas, indicando que o planejamento e a documentação são processos iterativos e contínuos (PMI, 2008, p. 46). O planejamento desta nova metodologia não detalha como o trabalho será feito e sim levanta uma visão de onde pretende chegar a partir do planejamento da qualidade, onde não pode haver falhas no planejamento de riscos e como alinhar as expectativas das partes interessadas com o planejamento da comunicação. O grupo de processos de planejamento organizam os processos conforme demonstrado na imagem abaixo.

96 96 Imagem X: Processos do planejamento. Fonte: o autor. Os tópicos abaixo descrevem detalhadamente cada um destes processos Classificar projeto Classificar projeto (P.1) Projetos são diferentes e exigem diferentes formas de serem guiados, por isso é importante classifica-los. Entrada Proposta Visto em Como fazer? Classificar projeto Gerente do projeto Geralmente projetos grandes e caros exigem muito mais documentação e planejamento do quê projetos pequenos e baratos. Acrescido a isto, alguns projetos são mais alinhados com a estratégia da empresa que

97 Classificar projeto (P.1) outros, exigindo maior atenção da diretoria, outros projetos utilizam tecnologia desconhecida ou possuem uma lista de riscos de alto impacto, outros possuem mais recursos humanos do quê existe atualmente, outros listam um alto número de entregas em curto prazo necessitando que haja uma micro gestão e por aí vai. XAVIER (2009, p.23) propõe que os projetos sejam classificados por orçamento e prazo no seguinte quadrante: Imagem X: Quadrantes de classificação de projetos Fonte: Adaptado de XAVIER, 2009, p. 23 Neste gráfico os projetos mais longos e caros estão no quadrante 1 e os menores estão no quadrante 6. Adicionei a profundidade escolha estratégica ou adaptada que permite ao gerente de projetos selecionar o quadrante do projeto de acordo com a estratégia, riscos, recursos ou outra classificação. Classificação adaptada de projetos Caso o enquadramento do projeto necessite de uma adaptação é aconselhável que utilize alguns critérios de classificação como sugerido por CURI (2009). Inicialmente pode ser necessário adaptar o conteúdo da tabela abaixo conforme a realidade da empresa.

98 Classificar projeto (P.1) Tabela X: Classificação de Projetos Fonte: (CURI, 2009, p. 35) O próximo passo é utilizar a tabela acima para identificar a importância, e inserir um peso (que deve estar de acordo com o ambiente da empresa), a multiplicação dos dois resulta no porte do projeto, conforme demonstra na tabela abaixo. Tabela X: Métrica de Classificação de Projetos Fonte: (CURI, 2009, p. 45) Ferramentas do projeto por classificação Gerente do projeto A partir desta classificação é possível definir, por projeto, quais documentos são obrigatórios, quais ações são

99 Classificar projeto (P.1) necessárias e qual nível hierárquico deve ser informado ou aprovar certas decisões. Segue um exemplo de uso, sendo que cada empresa adapta da forma que melhor se adapte: Documentos e ações que devem ser elaborados: Documento ou ação Classificação do projeto Mapa do projeto e mapa do escopo X X X X X X Estimativa de tempo e de custos X X X X X X Proposta comercial X X X X X X Cronograma X X X X X Identificar a qualidade X X X X Plano de gerenciamento da qualidade X X Identificar os riscos X X X X Plano de resposta aos riscos X X Mapa de comunicação X X X X X Mapa de responsabilidades X X X Arquitetura da informação X X X X Formação e manutenção do Kanban X X X Planejar entregas semanais X X X X Stakeholders participarem do processo X X X X Formação de equipe, líder e negociador X X X X Plano Integrado de Mudanças X X X Plano de gerenciamento de pessoal X X Aprovações requeridas (o numeral indica a sequência de aprovações): Aprovador Classificação do projeto Gerente de projetos Gerente de área Gerência de compras (se for adquirir bens ou serviços) Diretor da área Verificação Validar o projeto classificado Estratégicos da empresa A diretoria, presidência, analista de negócios ou um estratégico autorizado é responsável por aprovar e ajudar na classificação do projeto. Resultados Projeto classificado Um documento, ou somente uma definição, indicando a classificação escolhida para o projeto.

100 Analisar múltiplos projetos e definir equipe Analisar múltiplos projetos e definir equipe (P.2) Definir uma equipe não é um processo simples, empresas geralmente possuem vários projetos, e em muitos casos tanto a equipe quanto o próprio gerente de projetos estão distribuídos em mais de um projeto. E a empresa possui diversos projetos sendo executados simultaneamente e nem sempre há recursos disponíveis para iniciar um novo serviço imediatamente. Portanto é essencial que todos os projetos sejam analisados a fim de encontrar pessoas disponíveis, em determinadas datas, para assim definir quem fará parte da equipe deste novo projeto. Entrada Proposta Visto em Projetos em andamento Receber uma lista dos projetos em andamento, com datas de início e fim de cada pacote de trabalho ou fase e com a lista de seus recursos humanos com datas de início e fim de alocação. Como fazer? Atualizar o mapa de produção Controlador Listar todos os projetos em um único documento, com seus grupos de atividades, ou pacotes de trabalho. Para cada pacote de atividades terem seus recursos humanos listados. A ideia é ter uma visão completa da utilização de recursos, permitindo ao gerente de projetos e ao controlador, fazer uma análise tática, obtendo as seguintes informações: Qual profissional estará ocupado e quando; Qual profissional estará disponível para trabalhar em um novo projeto ou pacote de atividades; Se é necessário contratar, adquirir, um novo profissional; Se algum recurso ficará ocioso; Quando um projeto pode iniciar; Quando novo pedido e modificações poderão ser realizadas; A análise das fases do ciclo de vida é intuitiva, considerando que tal fase seja aprovada em uma determinada data, sendo também que os prazos não precisam ser os mesmos dos passados para os patrocinadores. Então, por exemplo, um layout pode ser aprovado em dois dias ou duas semanas, o controlador pode levantar informações com a equipe para prever e intuir qual o período provável de aprovação. Segue o exemplo de um mapa de produção, feito na ferramenta MS Project, de um ambiente de desenvolvimento WEB:

101 Analisar múltiplos projetos e definir equipe (P.2) Imagem X: Exemplo de um mapa de produção Fonte: o autor É possível realizar filtros por recursos e tipos de recursos, aumentando o nível de detalhamento. Sugerir a equipe Controlador Inserir as informações do novo projeto no mapa de produção, listando uma previsão de início, os recursos necessários e sequenciando seus trabalhos. Aplicar nas fases, ou pacotes de atividades, deste novo projeto as pessoas mais disponíveis para trabalhar. Depois, analisar se há sobreposição de trabalho, ou seja, o profissional está alocado em tempo integral a duas tarefas simultaneamente, trabalhando mais horas do quê o combinado. Se este for o caso XAVIER (2009, p. 67) lista as soluções mais comuns: Substituindo o recurso, contratando se for o caso; Trocar a escala de trabalho do recurso, trabalho e folga para compensar posteriormente (banco de horas); Trabalho em regime de horas-extras; e Nivelamento ou redistribuição de recursos, atrasando as atividades do recurso, o que pode atrasar o projeto se elas estiverem no caminho crítico. O controlador deve criar soluções em conjunto com o gerente de projetos. Encontrar as datas do projeto como: data de início, data de início previsto para cada fase ou pacote de atividades e data final. Por fim, após esta análise, o controlador pode sugerir a necessidade de contratação ou terceirização do serviço. Definir a equipe Gerente de projetos Analisar e validar a equipe sugerida e as datas encontradas. Pode ser que o planejamento anterior, do mapa de produção, seja alterado a fim de encontrar a menor data possível com a melhor equipe possível para o projeto. A análise do gerente de projeto tende a ser mais estratégica no sentido de agrupar pessoas que se complementam.

102 Analisar múltiplos projetos e definir equipe (P.2) O gerente de projetos pode decidir contratar ou terceirizar um profissional. XAVIER (2009, p. 66) diz que o gerente de projetos deve observar os seguintes fatores para escolher os recursos: Escopo do trabalho; Disponibilidade do recurso; Taxa ou produtividade do recurso; Custo; Capacitação profissional; Qualidade dos equipamentos e materiais. VER XAVIER, 106 se dá para aproveitar alguma coisa... Criar o plano de gerenciamento do pessoal Verificação Aconselhar equipe Equipe de planejamento Equipe de orçamento Tanto a equipe de planejamento quanto a equipe de orçamento, nesta fase, ainda são as pessoas que mais conhecem sobre o projeto. Portanto, é importante ouvir deles se a equipe definida possuem as melhores características para trabalhar no projeto. Confirmar equipe Equipe do projeto Ouvir da equipe selecionada para o projeto, os prós e os contras desta união e também se consideram uma parceria produtiva, e também levantar uma análise técnica da melhor formação para o grupo. Validar equipe do projeto Gerente de projetos A palavra final quanto a definição da equipe é sobre o gerente de projetos. Ele inclusive pode decidir se as verificações das equipes acima serão realizadas ou não. Resultados Mapa de produção criado ou atualizado Lista de recursos do projeto atualizada Um documento com a lista dos projetos e dos seus recursos alocados. Lista das pessoas que participarão do projeto, assim como a criação de um informativo formalizando tal participação e as principais datas Planejar aquisições e adquirir Planejar aquisições e adquirir (P.3)

103 Planejar aquisições e adquirir (P.3) O conceito de tipos de contratos foi fundamentado em 2.9. Para planejar as aquisições, devemos identificar as necessidades do projeto que serão melhor atendidas por meio da aquisição de produtos e/ou serviços fora de equipe do projeto. Aquisição aqui significa compra ou contratação, ou serviços para atender às necessidades do projeto. Entrada Declaração do escopo Visto em Solicitação de proposta Visto em Mapa do projeto (EAP) Visto em Lista de recursos do projeto Custo unitário dos recursos Visto em Os custos unitários dos recursos humanos, materiais e equipamentos. Mapa do produto Visto em Como fazer? Decidir fazer ou contratar Gerente de projetos Avaliar se devemos produzir os pacotes de trabalho internamente ou contratar terceiros para produzi-los. Para tomar esta decisão deve ser lavado em consideração (XAVIER, 2009, p.82): Facilidade de integração com as operações de rotina; Utilização da capacidade ociosa; Necessidade de controle direto; Existência de fornecedores confiáveis; Uso de mão de obra disponível; Necessidade de absorção da tecnologia; Custo; Prazo; Necessidade de fornecimento especializado; Restrições do projeto; e Capacidade da equipe. Para tanto é importante analisar os múltiplos projetos, a equipe disponível e principalmente o trabalho a ser feito visualizando de forma crítica o mapa do projeto e o mapa do produto. Aqui deve resultar em uma lista do que será contratado. Planejar a aquisição Gerente de projetos Decidido o que será contratado é importante fazer um planejamento da aquisição, ou seja, devemos planejar

104 Planejar aquisições e adquirir (P.3) quais atividades são necessárias para a solicitação de propostas e contratação. XAVIER (2009, p.83) criou um EAP ou uma lista de pacotes de trabalho, genérica, a ser realizada em uma aquisição, são elas: 1. Contratação do produto / serviço 1.1. Solicitar proposta de fornecedores Especificar o produto ou serviço Deve descrever o item a ser adquirido em suficiente detalhe para permitir aos fornecedores determinarem se eles são capazes de proverem o item e apresentarem suas propostas. Algumas empresas chamam de declaração de trabalho (SOW Statement of Work) e, o governo, de objeto da licitação Estabelecer critérios de avaliação (técnicos e comerciais) Os critérios de avaliação podem ser obrigatórios (pré-requisitos) ou facultativos (desejos que irão melhor qualificar as propostas). Eles serão usados para avaliar e classificar as propostas. Por exemplo, podem ser utilizados: preço e custo do ciclo de vida do produto, atendimento á necessidade do cliente, qualidade (ex: ISO 900x), capacidade técnica (ex: atestados de execução), capacidade de gerenciamento (ex: certificação PMP), capacidade financeira, garantia, referências e etc Elaborar pedido de proposta Um pedido de proposta ou de cotação é uma solicitação formal preparada pelo comprador, enviada para cada fornecedor, e é a base sobre a qual um fornecedor prepara uma proposta para os produtos, serviços ou resultados solicitados, que estão definidos e descritos no documento. Algumas empresas chama o pedido de Request for Quotation (RFQ) quando vão decidir pelo menor preço e de Request for Proposal (RFP) quando vão utilizar outros critérios, além do preço, para escolher o fornecedor. O governo utiliza o edital de licitação para esse propósito Levantar lista dos fornecedores qualificados Muitas empresas possuem um cadastro de fornecedores bem elaborado. A escolha dos fornecedores para os quais serão enviados os pedidos de proposta é um dos fatores para mitigação dos riscos de contratação. Se necessário, outros potenciais fornecedores podem ser buscados no mercado Divulgar pedido de proposta A divulgação do pedido de proposta pode ser por carta, , ou contato pessoal, entre os representantes do cliente e dos fornecedores. Ou outra forma de divulgação Receber propostas Os fornecedores devem ter um tempo adequado para a preparação das propostas. Dependendo da natureza do projeto, o pedido de propostas pode requerer a visita de representantes dos fornecedores às instalações onde o projeto será executado com fins de inspeção Contratar fornecedor Analisar propostas Aplicar os critérios de avaliação estabelecidos anteriormente, de forma a ter como resultado uma classificação das propostas recebidas Escolher fornecedor Quando existir uma quantidade grande de fornecedores, o processo de seleção dos mesmos deve ser em rodadas.

105 Negociar contrato Planejar aquisições e adquirir (P.3) Tem o objetivo de ajustar os termos contratuais às necessidades gerais do contratante e às específicas do projeto. Durante a negociação pretende-se obter condições justas e razoáveis para o contrato e desenvolver uma boa relação com o fornecedor Redigir contrato Normalmente o contrato é firmado no modelo do contratante Assinar contrato No planejamento dessa atividade deve ser levado em consideração o tempo de assinatura no cliente e no fornecedor. Algumas empresas emitem um documento (por exemplo, uma carta de intenção) para autorizar o início dos trabalhos enquanto o contrato tramita para assinatura. De acordo com o que precisamos contratar, devemos verificar quais dessas atividades serão realmente necessárias, acrescentando ou não outras atividades que, para o caso específico, devem ser realizadas. Contratar ou mobilizar equipe Gerente de projetos Com a lista de recursos disponíveis, recursos necessários, recursos a serem contratados (como visto em decidir fazer ou contratar) e com o planejamento da aquisição é o momento de contratar o pessoal que fará parte da equipe. De acordo com XAVIER (2009, p. 128) são três passos para contratar e mobilizar uma equipe: Pré-designar: quando os membros da equipe já são conhecidos antecipadamente; Negociar: processo de negociar, junto aos setores da empresa, os recursos humanos necessários ao projeto; e Contratar ou mobilizar: os recursos humanos não disponíveis devem ser contratados, inclusive considerando a opção de teletrabalho. Para a contratação é importante seguir os passos da EAP anterior (como visto em planejar a aquisição). Na contratação de profissionais terceiros, geralmente as empresas projetizadas possuem uma lista de profissionais no qual já trabalharam, outros casos as pessoas da empresa possuem uma lista de conhecidos. Estes meios agilizam a aquisição, mas não deixam de ampliar os riscos, portanto o planejamento e o contrato devem estar muito bem produzidos. Outras vezes acontece a contratação do tipo homem/hora o quê não dispensa um planejamento e nem um contrato, apesar destes ficarem mais simples. Em todos os casos, estas contratações são essenciais para o bom andamento do projeto que está iniciando e, deve ser avaliado inclusive se o projeto irá esperar a aquisição para ser iniciado, ou se, é possível que este profissional (ou outra aquisição) comece a trabalhar posteriormente no projeto. Se for o caso do último, todas as decisões e comunicações feitas, que o impactam, devem ser registradas de tal forma que, o contratado, ao entrar seja completamente atualizado. Propor modificações no projeto Gerente de projetos Algumas aquisições podem variar o custo e prazo do projeto e devem ser separadas em um documento, e não podem ser realizadas enquanto não receberem aprovação. Geralmente estas aquisições são justificadas por aumentarem a qualidade ou reduzirem probabilidade de riscos. Verificação

106 106 Revisar aquisições Planejar aquisições e adquirir (P.3) Equipe do projeto Equipe de planejamento Equipe de orçamento Podem ser feitos brainstormings, entrevistas ou um simples levantamento, com todos os membros do projeto, a fim de, levantar todas as aquisições necessárias e, inclusive, qual a melhor forma de adquiri-los, com indicações e referências históricas. Aprovar aquisições internas Responsável pelo financeiro As aquisições adquiridas por quem está produzindo o projeto devem ser aprovadas por um responsável do financeiro, pela pessoa que irá conseguir recursos financeiros para o projeto. Aprovar aquisições externas Equipe do cliente As aquisições geradoras de custos para o cliente devem ser aprovadas pela equipe do cliente. Resultados Lista de recursos do projeto atualizada Contratos Planejamento da aquisição Propostas de modificações no projeto Atualizar a lista de recursos do projeto, adicionando as novas contratações. Uma série de contratos que devem ser administrados até o encerramento do projeto. Um documento com datas limite das aquisições e definições de qualidade para estas. Documento propondo modificações no projeto devido ao planejamento de aquisições Criar cronograma Criar cronograma (P.4) O conceito de criar cronograma foi fundamentado em Aplicar datas e calendário, assim como suas restrições, na estimativa de tempo. Entrada Estimativa de tempo Visto em Lista de recursos do projeto Visto em e Planejamento da Visto em

107 Criar cronograma (P.4) aquisição Como fazer? Gerar o cronograma Gerente de projetos Consiste basicamente em determinar as datas de início e término das atividades do projeto. Para isto, utilizaremos o trabalho feito em estimar tempo, no qual as atividades foram sequenciadas, os recursos necessários para sua execução previstos e a duração de cada atividade estimada. Agora sabemos quais recursos executarão as atividades e também sabemos a data de start do projeto. Com isto conseguimos aplicar informações valiosas como feriados, finais de semana, folgas, horas de trabalho e disponibilidade de recursos a fim de calcular as datas de entrega do projeto. Segue um exemplo de cronograma: Imagem X: Exemplo de um cronograma Fonte: o autor Neste exemplo os pacotes de trabalho estão fechados, cada pacote de trabalho possui suas atividades e cada atividade possui seus recursos, duração e sequenciamento. O sequenciamento das atividades sequencia os pacotes de trabalho. Se o projeto utilizar mais de dez pessoas simultaneamente, etapas ou fases do projeto devem ser criadas, prevendo que formem grupos de no máximo dez pessoas. Ou se o projeto durar mais de dois meses, então ele deve ser dividido em fases. Identificar o caminho crítico Gerente de projetos Para chegarmos ao final do projeto temos que percorrer vários caminhos, estes foram criados no sequenciamento das atividades. O caminho crítico é o maior dos caminhos do projeto, sendo as suas atividades normalmente consideradas as mais importantes, pois qualquer atraso nestas atrasará o projeto XAVIER (2009, p. 68). O caminho crítico tem que ser conhecido e entendido por todos. Este conhecimento facilita na tomada de decisões e alocações de recursos. Dessa forma, todos saberão quem não pode ter o trabalho adiado. Geralmente a redução do prazo no projeto é realizada em cima das atividades que compõem o caminho crítico. Rever a duração do projeto Gerente de projetos Agora que foram aplicadas as restrições de recursos e de calendário ao projeto, pode ser que as datas e prazos

108 Criar cronograma (P.4) estejam muito acima do combinado entre as partes. Para isto, existem duas técnicas que podem ser empregadas: Compressão (Crashing): adição de recursos; Caminho rápido (Fast tracking): realizar atividades em paralelo. Maiores detalhes destas técnicas podem ser vistos em O uso destas técnicas merece cuidado já que aumentam os riscos do projeto. Outra técnica a ser empregada é a divisão da entrega em sub entregas. Muitas vezes, existem atividades chave que podem ser lançadas antes do todo, viabilizando o alcance do objetivo, mesmo antes do projeto todo estar pronto. As sub entregas muitas vezes causam conforto entre as partes, permitindo uma entrega inicial na parte prevista e outra em um período posterior. Se o período entre a criação da proposta na iniciação e a aprovação da proposta for muito grande, então pode ser que a realidade da produção e a alocação dos recursos seja diferente do previsto, portanto se for o caso, o ideal é que seja comunicado que a realidade do atual cenário provocou mudança no prazo do cronograma. Tal regra deve estar prevista no contrato. Dividir o projeto em fases Gerente de projetos É muito importante que o projeto não tenha um trabalho maior que dois meses para realizar uma entrega. Se este for o caso, o gerente de projetos deve dividir o projeto em fases. Se o projeto utilizar mais de dez pessoas simultaneamente, etapas ou fases do projeto devem ser criadas, prevendo que formem grupos de no máximo dez pessoas. Verificação Validar datas e alocação de equipes Controlador O controlador com o seu mapa de produção e visão do todo, será responsável por validar se a equipe estará disponível na data planejada no cronograma. Revisar cronograma com a equipe Equipe do projeto É importante que os participantes do projeto validem as atividades que executarão no prazo e período estimado. Esta revisão tende a trazer qualidade para o cronograma e a alinhar a comunicação com todos. Validar cronograma externamente Equipe do cliente O cliente deve receber o cronograma sumarizado de modo que veja pacotes de trabalho agrupando atividades e as principais entregas. Normalmente, este cronograma não é destacado ao cliente, já que no processo de planejar a comunicação é criado um cronograma macro, informando as principais entregas e simplificando a visualização. Validação final do cronograma Gerente de projetos O gerente do projeto deve revisar e garantir se o cronograma é viável e exequível, e sua decisão deve ser a última, mesmo quando existam pressões externas para a redução do prazo. Resultados

109 Criar cronograma (P.4) Cronograma do projeto Estimativa de tempo atualizada Lista de recursos do projeto atualizada Planejamento da aquisição atualizado O cronograma apresenta a data planejada para início e a data esperada para a conclusão de cada atividade do projeto. Atualização da alocação dos recursos nas atividades e até no sequenciamento destas. Pode ser que o cronograma altere os recursos do projeto. O cronograma atribuiu datas iniciai e finais as atividades, portanto, o planejamento de aquisições tende a ser alterados com estas datas Formar equipe, líder e negociador Formar equipe, líder e negociador (P.5) O conceito deste processo foi fundamentado em 2.5 e 2.7. Reunir a equipe, formalizando a união e definir o líder e o negociador do projeto. Entrada Lista de recursos do projeto Planejamento da aquisição Visto em e Visto em Mapa do produto Visto em Mapa do projeto Visto em Proposta Visto em Cronograma Visto em Declaração do escopo Visto em Relação das partes interessadas do projeto Visto em Como fazer? Reunir a equipe prevista Gerente de Projetos Reunir a equipe, apresentar a todos e introduzir o projeto. Se a equipe ainda não se conhece é interessante que cada um diga informações que agregam, como nome,

110 Formar equipe, líder e negociador (P.5) experiência em outros projetos, em outras empresas, cursos, estudos e como pensa estar no futuro. Também pode ser levantada a expectativa que cada um tem para este projeto e o que ele acredita ser os pontos positivos e negativos deste trabalho. Esta reunião pode ser considerada a reunião de start do projeto como visto no tópico Fazer uma apresentação completa do projeto, neste momento é essencial que a equipe do planejamento e também do orçamento estejam presentes e eles que apresentem o projeto. Todos os documentos feitos até o momento são exibidos e explicados pelos responsáveis que o criou. Um ponto importante a ser informado aqui é sobre a relação das partes interessadas e suas características, muitas decisões e posturas são formadas com tais informações. Definir líder Equipe do projeto Apresentar as responsabilidades do líder do projeto (vistas nos processos abaixo). Realizar uma votação de escolha do líder, as regras podem variar, mas o ideal que seja aberto e transparente, onde os membros indicam a pessoa e falam o motivo da escolha. Se não houver uma decisão clara, uma solução seria repetir o processo, bloqueando o voto em si mesmo. Ou se não houver um acordo entre todos, pode ser necessário voltar aos processos anteriores e reformular a equipe. Em última instância o Gerente de Projetos pode intervir como um voto ou organizando a votação de modo que um líder seja selecionado. A pessoa escolhida para ser líder, depois da votação, tem que aceitar ou rejeitar a tarefa, caso contrário outro líder será escolhido. A pessoa que não aceitar tem que explicar o motivo. O líder é um membro da equipe do projeto! Definir negociador Equipe do projeto Apresentar as responsabilidades do negociador do projeto (vistas nos processos abaixo). Realizar uma votação de escolha do negociador, as regras podem variar, mas o ideal que seja aberto e transparente, onde os membros indicam a pessoa e falam o motivo da escolha. Se não houver uma decisão clara, uma solução seria repetir o processo, bloqueando o voto em si mesmo. Ou se não houver um acordo entre todos, pode ser necessário voltar aos processos anteriores e reformular a equipe. Em última instância o Gerente de Projetos pode intervir como um voto ou organizando a votação de modo que um negociador seja selecionado. A pessoa escolhida para ser negociador, depois da votação, tem que aceitar ou rejeitar a tarefa, caso contrário outro negociador será escolhido. A pessoa que não aceitar tem que explicar o motivo. O negociador é um membro da equipe do projeto! Definir controlador da qualidade Equipe do projeto Apresentar as responsabilidades do controlador da qualidade (vistas nos processos abaixo). Realizar uma votação de escolha do controlador da qualidade, as regras podem variar, mas o ideal que seja aberto e transparente, onde os membros indicam a pessoa e falam o motivo da escolha. Se não houver uma decisão clara, uma solução seria repetir o processo, bloqueando o voto em si mesmo. Ou se não houver um acordo entre todos, pode ser necessário voltar aos processos anteriores e reformular a equipe. Em última instância o Gerente de Projetos pode intervir como um voto ou organizando a votação de modo que um controlador da qualidade seja selecionado. O controlador da qualidade é um membro da equipe do projeto!

111 111 Formar equipe Formar equipe, líder e negociador (P.5) Equipe de projeto Formar equipe é um processo empírico sendo amadurecido no decorrer do projeto e dos múltiplos projetos. KEEN (2003) indica que antes que uma equipe comece a trabalhar em qualquer tarefa, três fatores básicos devem ser estabelecidos pela equipe: Missão do time - porque o time existe; Objetivos do time - o que o time espera conseguir, e Regras - como o time será administrado e como os objetivos serão alcançados e o progresso medido. Portanto esta metodologia forma equipes utilizando os processos do planejamento, da seguinte maneira: Na missão do time, o time identifica por que ele existe e a reunião de START pode ser que responda esta questão, ou pode ser necessário detectá-la por outros meios. o Arthur Diniz da crescimentum.com.br sugere a construção conjunta do sonho onde a equipe responde: Independente das metas definidas pela empresa, que realização vai nos deixar orgulhosos de fazer parte dessa equipe? ; Para o objetivo do time, a ideia é que o processo da qualidade execute ferramentas que detecte o objetivo que todos almejam alcançar; O objetivo é formado pelo custo, cronograma, qualidade e escopo. Já para as regras do time, é alcançado pelo processo da qualidade, pelo processo dos riscos e pelo processo de comunicação. Também é importante que o time discuta, modifique, e entenda as regras já existentes encontradas nos processos da metodologia, no cronograma, nas aquisições, nos custos e no escopo do projeto. Já KATZENBACH e SMITH (2001), definem a equipe como: um grupo de pessoas com aptidões complementares, comprometidas com um objetivo comum, que realizam trabalho interdependente e são coletivamente responsáveis pelos resultados. Portanto, além do objetivo comum, as equipes devem ser coletivamente responsáveis pelos resultados. Sendo assim, os processos seguintes incentivam a participação de todos e também a distribuição de responsabilidades para todos os membros do time. Se profissionais terceirizados forem trabalhar no projeto, eles devem ser considerados como equipes do projeto e participar de todos os eventos no qual a equipe do projeto estarão juntas. Verificação Validar líder e negociador Equipe do projeto Ao fim, todos tem que estar de acordo com a decisão de quais pessoas serão líder e negociador, caso contrário, repetir o processo ou até redefinir a equipe do projeto. Resultados Lista de recursos do projeto atualizada Planejamento da aquisição Atualizar a lista dos recursos com as informações levantadas neste processo como: quem é líder, quem é negociador, pontos positivos e negativos detectados no início do projeto e expectativas. Pode ser que algumas contratações não se encaixem com a equipe do

112 112 atualizado Visão da equipe Formar equipe, líder e negociador (P.5) projeto, exigindo uma revisão e alteração do planejamento da aquisição. Documento com o objetivo, missão e regras do time. É recomendável que este documento esteja visível a todos Equipe planejar a qualidade Equipe planejar a qualidade (P.6) O conceito de identificar a qualidade foi fundamentado em 2.6. Equipe realizar um brainstorming a fim de encontrar a qualidade do projeto, como alcança-la com estratégias e distribuição das responsabilidades e, por fim, converter esta qualidade em objetivo do projeto. Conforme percebido por ROSE (2005) e VALLE (2011) que analisaram várias definições de qualidade destacando ISO, NBR, ASQ e PMBOK, qualidade pode ser definida como atender as necessidades dos clientes. Entrada Proposta Visto em Lista de recursos do projeto Planejamento da aquisição Visto em Visto em Visão da equipe Visto em Como fazer? Identificar a qualidade Líder O conceito de identificar a qualidade foi fundamentado em O líder tem como responsabilidade incentivar para que todos da equipe do projeto participem do processo. Apesar de o líder ser o responsável, no princípio, o gerente de projetos pode ajuda-lo a conduzir a reunião. A identificação da qualidade é feita por todos os membros da equipe do projeto, por meio de brainstorming, onde todos falam e participam dos passos até preencherem a totalidade das ferramentas descritas abaixo. Esta participação alinha a comunicação e cria reflexão sobre o cliente e o projeto, preenchendo na equipe do projeto a sabedoria da qualidade. Eles conhecem e sabem o porquê das decisões, criando uma visão única. E também criam a noção de onde querem chegar e de onde não podem ultrapassar.

113 Equipe planejar a qualidade (P.6) O líder conduz a reunião solicitando que todos respondam e discutam. As médias das respostas se convertem em um único valor. Todas as ferramentas e repostas devem estar preenchidas em um quadro, vidro ou projeção visíveis a todos os participantes. Os passos para a identificação da qualidade são: Passo 1: identificar os clientes; Passo 2: priorizar os clientes; Passo 3: identificar as necessidades; Passo 4: priorizar as necessidades por cada cliente; Passo 5: priorizar as necessidades do projeto; O primeiro passo para identificar a qualidade é o de identificar os clientes do projeto, portanto o líder deve conduzir a reunião de modo que a equipe identifique no mínimo cinco clientes. Depois de identificados, os clientes devem ser priorizados utilizando a matriz em forma de L, exemplificada na tabela abaixo. Cliente 1 Cliente 2 Cliente 3 Cliente 4 Cliente 5 Total da linha Valor decimal relativo (total da linha / total geral) Cliente /5 16,2 0,31 Cliente 2 1/5 1/ ,4 0,05 Cliente /10 11,1 0,21 Cliente 4 1/10 1 1/5 5 6,3 0,12 Cliente /5 16,2 0,31 Total Geral 52,2 Tabela X: Priorizando clientes com a Matriz em forma de L Fonte: Adaptado de ROSE, 2005, p. 46. Percebe-se que alguns clientes possuem nota muito baixa como o cliente 2 no exemplo acima. Esta metodologia recomenda ignorar clientes com valor decimal abaixo de 0,1 nos passos seguintes. Para o terceiro passo, é necessário identificar no mínimo cinco necessidades do projeto. No quarto passo, para cada cliente devemos priorizar suas necessidades. Veja abaixo um exemplo das necessidades do cliente 1: Cliente 1 Necessidade 1 Necessidade 2 Necessidade 3 Necessidade 4 Necessidade 5 Total da linha Valor decimal relativo (total da linha / total geral) Necessidade /5 16,2 0,31 Necessidade 2 1/5 1/ ,4 0,05 Necessidade /10 11,1 0,21 Necessidade 4 1/10 1 1/5 5 6,3 0,12 Necessidade /5 16,2 0,31 Total Geral 52,2 Tabela X: Priorizando necessidades de clientes com a Matriz em forma de L Fonte: Adaptado de ROSE, 2005, p. 51.

114 Equipe planejar a qualidade (P.6) É criado um quadro igual a este para cada cliente, sendo as necessidades são as mesmas para todos os clientes, e o que varia são as notas e valores. Para o quinto passo, todas as tabelas acima são relacionadas em uma única matriz permitindo que priorizemos as necessidades do projeto. Tabela X: Priorizando necessidades do projeto Fonte: VALLE, 2012, adaptado de ROSE, 2005, p. 55. As fórmulas e cálculos podem ser automatizados em uma planilha eletrônica o que agiliza todo o processo. Para isso, o líder pode escolher uma pessoa para repassar as notas do quadro para a planilha e este ler em voz alta os valores. Detalhes de como realizar os cálculos são vistos no tópico 2.6. Identificar plano de ação da qualidade Equipe do projeto O líder tem como responsabilidade incentivar para que todos da equipe do projeto participem do processo. Para cada uma das principais necessidades (com maior nota): fazer um brainstorming das ações necessárias para alcançar aquela necessidade. Toda a equipe participa informando e principalmente discutindo entre si, levantando o que deve ser feito e alterado no projeto e assim criando uma lista de ações agrupadas por necessidade. Cada ítem da lista de ação possui: O quê: que é a ação identificada; Porque: normalmente é para atingir a necessidade; Como: detectar no debate e registrar um descritivo de como esta ação será realizada; Distribuir responsabilidades da qualidade Equipe do projeto O líder tem como responsabilidade incentivar para que todos da equipe do projeto participem do processo. Depois de identificadas as ações, a próxima tarefa da equipe é definir o responsável por executar a ação. Nenhuma ação pode ter dois responsáveis, se assim for detectado, tentar mudar nomenclatura e dividir esta ação em duas ou mais.

115 Equipe planejar a qualidade (P.6) Quando o responsável for identificado, ele deve responder: Quando: o momento do projeto, ou uma data no calendário, no qual o gatilho de execução da ação é disparado. O ideal é seguir o cronograma; Onde: local da aplicação da ação, como exemplo: o pacote de trabalho, a atividade,...; Quanto: se a equipe sentir que a ação tende a gerar custo ou mudar o escopo, o responsável deve estimar o tempo e custo para a sua execução. A estimativa de quanto não precisa ser feita em reunião; A ideia é que toda ação proposta siga o checklist 5W2H: What? (O quê?), Why? (Por quê?), Who? (Quem?), Where? (Onde?), When? (Quando?), How? (Como?), How much? (Quanto custa?). O resultado da distribuição é um documento, preenchido por um membro selecionado pelo líder, distribuindo as responsabilidades os membros da equipe. Refinar planejamento e critério de aceitação para a qualidade Equipe do projeto A identificação de qualidade, as ações para atingir a qualidade e a distribuição de responsabilidades estarão disponíveis para os membros da equipe do projeto. Deve ser combinado com todos que, após a reunião, eles possuem um período (por exemplo: até uma semana) para revisar e refinar suas ações. Com isto, as ações ficam apresentáveis, o planejamento realista, o documento melhor acabado e principalmente o responsável aprofunda o conhecimento do quê será feito. Também é adicionado ao planejamento (5W2H) o campo critério de aceitação como uma métrica. Este campo dita logicamente o quê garantirá que a qualidade foi atingida. Dessa forma, fica claro para todos se a qualidade está sendo cumprida. De acordo com XAVIER (2009, p. 101), critério de aceitação é o nível de qualidade a ser atingido pelo produto ou serviço para que seja considerado satisfatório e, consequentemente, aceito pelo cliente. Por exemplo: O software processa transações/hora; O equipamento suporta temperaturas de -10 a 40 graus Celsius e variações de até 2 graus/minuto; e A edificação suporta ventos de até 100Km/h sem comprometer sua solidez. XAVIER sugere o uso de outro campo que é o método de verificação que estabelece o processo / procedimento para medir / avaliar o requisito. Por exemplo: Testes funcionais e de desempenho (softwares); Ensaios (equipamento); e Inspeções e avaliações. Criar objetivo do projeto Líder O líder, com o suporte do gerente de projetos, deve utilizar as informações da qualidade para criar o objetivo do projeto. O ideal é criar um objetivo curto, direto e fácil de entender que fique sempre visível para a equipe e para os demais stakeholders, sendo o objetivo um guia e um direcionador para todo o esforço do projeto. Criar lista de verificação da qualidade Controlador da qualidade O gerente de projetos pode criar um checklist ou lista de verificação da qualidade como resultado deste processo. Esta lista relaciona sob forma de perguntas ou afirmações (Fez isso? / Faça isso) as verificações que devem ser feitas sobre o produto gerado para que este seja avaliado quanto à sua conformidade com os requisitos (XAVIER,

116 , p. 101) Equipe planejar a qualidade (P.6) A ideia é criar uma lista de perguntas, agrupadas por fases, profissionais ou marcos de entrega. Propor modificações no projeto para a qualidade Gerente de projetos Algumas ações criadas para atingir a qualidade impactam o custo e prazo do projeto e devem ser separadas em um documento, e não podem ser executadas enquanto não receberem aprovação. A equipe deve calcular o custo e estimativa de prazo de cada uma destas modificações. Verificação Validar qualidade Equipe do projeto A equipe do projeto é a responsável pelo resultado deste processo, validando se a qualidade identificada, as ações para alcançar as necessidades e o objetivo criado estão corretos e apresentáveis. Revisar qualidade Gerente de projetos O gerente de projetos utilizará seus conhecimentos e visão estratégica para dar suporte a equipe na qualidade nos planos de ações identificados. Como o critério de aceitação foi feito individualmente, é provável que o responsável pela ação necessite de uma revisão sobre suas métricas. O gerente de projetos tem que revisar a qualidade do material e treinar a equipe para melhorar se este for o caso. Resultados Visão da equipe atualizada Plano de gerenciamento da qualidade Propostas de modificações no projeto atualizada Atualização no objetivo e nas regras com a distribuição das responsabilidades. Lista de clientes e necessidades identificadas e priorizadas. Registro dos planos de ações com atribuição dos responsáveis. Descrição e plano de como controlar e garantir a qualidade com suas métricas e critérios de aceitação. Documento propondo modificações no projeto devido ao planejamento da qualidade Equipe planejar os riscos Equipe planejar os riscos (P.7)

117 Equipe planejar os riscos (P.7) O conceito de identificar os riscos foi fundamentado em Reunir a equipe e realizar um brainstorming a fim de encontrar os riscos, levantar estratégias e distribuir responsabilidades. Entrada Proposta Visto em Lista de recursos do projeto Planejamento da aquisição Visto em Visto em Mapa do projeto (EAP) Visto em Mapa do produto Visto em Visão da equipe Visto em Plano de gerenciamento da qualidade Visto em Cronograma Visto em Relação das partes interessadas do projeto Visto em Como fazer? Identificar riscos Líder O conceito de identificar os riscos foi fundamentado em A identificação dos riscos é feita por todos os membros da equipe em um brainstorming. É essencial detectar também os riscos positivos do projeto. É importante utilizar todas as informações levantadas até o momento como: mapa do projeto, mapa do produto, relação das partes interessadas, cronograma, plano de gerenciamento da qualidade, planejamento da aquisição, lista de recursos e proposta. Estes documentos tem que estar visíveis para todos os presentes. Debater cada pacote de atividades do mapa do projeto e também do mapa do produto, a fim de identificar algum risco positivo ou negativo. Levantar riscos de comunicação, problemas, conflitos e soluções de relacionamento analisando a relação das partes interessadas. Identificar riscos também a partir das principais entregas previstas no cronograma. Com o planejamento da aquisição e lista de recursos detectar forças e fraquezas internas. Também é possível levantar oportunidades e ameaças analisando forças externas como cliente e mercado. Por fim, podem ser utilizadas as áreas de conhecimento como exemplificado por XAVIER (2009, p. 88):

118 Equipe planejar os riscos (P.7) Escopo Qualidade Tempo Custo Aquisições RH Comunicações Integração Risco Riscos associados a mudanças de escopo, adaptações para se atingirem os entregáveis técnicos. Falhas para completar tarefas que exigem um requerido nível técnico ou performance de qualidade. Falhas para completarem as atividades dentro de limites de tempo estimados, ou associados com a dependência lógica da rede. Falhas para completar as tarefas dentro dos limites de orçamentos estimados. Falhas no recebimento do contratado. Falhas de recrutamento, seleção, avaliação de desempenho, remuneração, benefícios, incentivos, treinamento e relacionamento. Falhas na coleta / recuperação de informações, tabulação e distribuição das informações. Falhas no controle integrado de mudanças. Falhas no monitoramento e controle de riscos. Tabela X: Exemplos de riscos nas áreas de conhecimento Fonte: XAVIER, 2009, p. 88. As descrições dos riscos identificados devem estar escritos em um quadro, vídeo, projetor ou outro meio em quê todos possam acompanhar o preenchimento. Normalmente, no brainstorming, para cada risco, também são levantadas as causas e os sintomas (que ele causa). Estes também são anotados na identificação. Qualificar riscos Equipe do projeto Finalizada a identificação dos riscos é o momento de qualifica-los, atribuindo notas a probabilidade e ao impacto. Probabilidade: muito alta (0,9), alta (0,7), moderada (0,5), baixa (0,3), muito baixa (0,1); Impacto: muito alto (0,9), alto (0,7), moderado (0,5), baixo (0,3), muito baixo (0,1); Cada risco deve possuir uma probabilidade e um impacto! Para alinhar a comunicação e ajudar os participantes na análise do grau de impacto existe a opção de deixar à vista o dicionário ou escala de impacto, como no exemplo abaixo: Objetivo projeto Custo Cronograma do Muito (0,1) baixo Aumento insignificante do custo do projeto Atraso insignificante Escopo Redução do escopo não perceptível Qualidade Degradação da qualidade não perceptível Escala de impacto Baixo (0,3) Moderado (0,5) Alto (0,7) Muito alto (0,9) Até 5% de aumento Entre 5% e 10% de aumento Até 5% de atraso Entre 5% e 10% de atraso Áreas menos importantes do escopo são afetadas Apenas aplicações mais críticas são afetadas Áreas importantes escopo afetadas do são Redução de qualidade requer aprovação do cliente Entre 10% e 20% de aumento Entre 10% e 20% de atraso Redução do escopo inaceitável pelo cliente Redução de qualidade inaceitável pelo cliente Acima de 20% de aumento Acima de 20% de atraso Produto final é inútil para o cliente Produto final não é utilizável

119 Equipe planejar os riscos (P.7) Tabela X: Exemplos de riscos nas áreas de conhecimento Fonte: XAVIER, 2009, p Assim que todos os riscos estejam qualificados, a ideia é que exista uma tabela semelhante com a seguir: Número risco do Descrição do risco 1 Opcional Opcional 2 Opcional Opcional Causas Sintomas Probabilidade Impacto Escore (probabilidade X impacto) Tabela X: Exemplo de uma tabela com o resultado da qualificação dos riscos Fonte: o autor. Selecionar estratégias de respostas aos riscos Equipe do projeto Selecionar qual o tipo de estratégia a ser aplicada ao risco a fim de reduzir as ameaças e potencializar as oportunidades. Esta seleção é feita pelo time, em um brainstorming onde, para cada risco identifica é aplicado uma das estratégias listadas abaixo. De acordo com XAVIER (2009, p. 95), as estratégias para os riscos podem ser: Eliminar Transferir Mitigar Aceitar Explorar Compartilhar Estratégias para riscos negativos ou ameaças Alterar o plano do projeto para eliminar a ameaça ou proteger os objetivos do projeto de seus impactos ou para flexibilizar o objetivo que está sendo ameaçado, como extensão do cronograma ou redução do escopo. Nem sempre é possível, mas alguns riscos podem ser eliminados. Adotar uma abordagem tradicional em vez de uma inovadora é um exemplo. Outro seria a redução do escopo do projeto. O esclarecimento dos requisitos, obtenção de informações, melhoria da comunicação ou aquisição de especialização podem prevenir alguns riscos que surgem no início do projeto. Consistem em transferir para terceiros as consequências de um impacto negativo, porém não os elimina. Um exemplo seria a adoção de um contrato por preço global, onde o vendedor arca com os custos de eventos inesperados. Outros exemplos seriam: contratação (procurement), uso de seguro (pure risks), bônus por desempenho, fianças e Garantias Técnica que busca reduzir o impacto e/ou a probabilidade dos eventos de risco. Um sistema de servidores redundantes é um exemplo de mitigação. Outros exemplos seriam: adotar processos menos complexos, conduzir testes mais completos e planejados, escolher um fornecedor mais estável, prototipar o desenvolvimento de um produto que adote uma solução técnica inovadora, projetar redundância de um sub-sistema, para atender as falhas de produção. Esta técnica indica que o time de projeto resolveu não alterar o plano do projeto para lidar com um risco ou foi incapaz de identificar outra estratégia aplicável. A aceitação ativa indica que o time desenvolveu um plano de contingência, enquanto que a aceitação passiva indica que o time decidiu tratar dos riscos quando estes ocorrerem. A resposta de aceitação de riscos mais comum é a determinação de uma margem ou reserva de contingência, seja em termos financeiros ou de tempo. Estratégias para riscos positivos ou oportunidades Visa garantir que a oportunidade seja concretizada. Tenta eliminar a incerteza associada a um risco positivo específico fazendo com que a oportunidade definitivamente aconteça. A exploração de forma direta das respostas considera a designação de recursos mais qualificados para o projeto a fim de minimizar o tempo de conclusão o obter uma qualidade maior do que a originalmente planejada. Técnica utilizada quando se percebe que um terceiro é capaz de aproveitar melhor as vantagens do risco, em prol do projeto. Fazer alianças através de parcerias, ou até mesmo joint-ventures, permite compartilhar os riscos visando gerenciar oportunidades.

120 120 Melhorar Aceitar Preparar contingência Calcular reserva de contingência Definir respostas aos riscos a Equipe planejar os riscos (P.7) Técnica que visa modificar o tamanho de uma oportunidade aumentando a probabilidade e/ou os impactos positivos de um risco, identificando e maximizando os principais acionadores desses riscos de impacto positivo. A probabilidade de êxito pode ser aumentada quando atuamos proativamente para o risco positivo acontecer. Esta técnica indica que o time de projeto resolveu não alterar o plano do projeto para lidar com um risco ou foi incapaz de identificar outra estratégia aplicável. Estratégias para respostas contingenciadas Resposta planejada para fazer frente à ocorrência de um evento específico. Neste caso, por exemplo, a equipe receberá um alerta se marcos intermediários não foram cumpridos. Se um terceiro atrasou uma entrega, a equipe deverá preparar a contingência para um novo atraso. A reserva de contingência pode abranger os fundos, o orçamento ou o tempo necessário, além da estimativa, para reduzir o risco de ultrapassar os objetivos do projeto a um nível aceitável para a organização. Tabela X: Estratégias de respostas aos riscos Fonte: XAVIER, 2009, p.95. Equipe do projeto O líder tem como responsabilidade incentivar para que todos da equipe do projeto participem do processo. Para cada um dos principais riscos (com maior escore): fazer um brainstorming das ações necessárias para alcançar a estratégia selecionada. Toda a equipe participa informando e principalmente discutindo entre si, levantando o que será feito e alterado no projeto e assim criando uma lista de ações agrupadas por estratégia do risco. Cada item da lista de ação possui: O quê: que é a ação identificada; Porque: normalmente é para atingir a estratégia; Como: detectar no debate e registrar um descritivo de como esta ação será realizada; Distribuir responsabilidades dos riscos Equipe do projeto O líder tem como responsabilidade incentivar para que todos da equipe do projeto participem do processo. Depois de identificadas as ações, a próxima tarefa da equipe é definir o responsável por executar a ação. Nenhuma ação pode ter dois responsáveis, se assim for detectado, tentar mudar nomenclatura e dividir esta ação em duas ou mais. Quando o responsável for identificado, ele deve responder: Quando: o momento do projeto, ou uma data no calendário, no qual o gatilho de execução da ação é disparado. O ideal é seguir o cronograma; Onde: local da aplicação da ação, como exemplo: o pacote de trabalho, a atividade,...; Quanto: se a equipe sentir que a ação tende a gerar custo ou mudar o escopo, o responsável deve estimar o tempo e custo para a sua execução. A estimativa de quanto não precisa ser feita em reunião; A ideia é que toda ação proposta siga o checklist 5W2H: What? (O quê?), Why? (Por quê?), Who? (Quem?), Where? (Onde?), When? (Quando?), How? (Como?), How much? (Quanto custa?). O resultado da distribuição é um documento, preenchido por um membro selecionado pelo líder, distribuindo as responsabilidades aos membros da equipe. Refinar planejamento dos riscos Equipe do projeto Todos os riscos identificados, suas estratégias e seus planos de ação serão compartilhados para toda a equipe do

121 121 projeto Equipe planejar os riscos (P.7) Deve ser combinado com todos que, após a reunião, eles possuem um período (por exemplo: até uma semana) para revisar e refinar suas ações. Com isto, as ações ficam apresentáveis, o planejamento realista, o documento melhor acabado e principalmente o responsável aprofunda o conhecimento do quê será feito. Propor modificações no projeto para os riscos Gerente de projetos Algumas ações criadas para reduzir a ocorrência de riscos impactam o custo e prazo do projeto e devem ser separadas em um documento, e não podem ser executadas enquanto não receberem aprovação. A equipe deve calcular o custo e estimativa de prazo de cada uma destas modificações. Verificação Validar riscos e estratégias Equipe do projeto A equipe do projeto é a responsável pelo resultado deste processo, validando se os riscos identificados e se as ações para alcançar as estratégias estão corretas e apresentáveis. Revisar riscos Gerente de projetos O gerente de projetos utilizará seus conhecimentos e visão estratégica para dar suporte a equipe quanto aos riscos identificados e os planos de ações listados. O gerente de projetos tem que revisar a qualidade do material e treinar a equipe para melhorar se este for o caso. Resultados Visão da equipe atualizada Plano de gerenciamento dos riscos Propostas de modificações no projeto atualizada Atualização nas regras com a distribuição das responsabilidades. Lista de riscos identificados e priorizados. Registro dos planos de ações com atribuição dos responsáveis. Descrição e plano de como controlar os riscos. Documento propondo modificações no projeto devido ao planejamento dos riscos Planejar a comunicação Planejar a comunicação (P.8)

122 Planejar a comunicação (P.8) O conceito de comunicação e do mapa de comunicação foi fundamentado em 2.4 e Este processo irá planejar a geração e distribuição das informações do projeto assim como prever a gestão das expectativas das partes interessadas. Outro objetivo deste processo é conscientizar e também incentivar que todos pensem e preocupem com a comunicação do projeto. Entrada Lista de recursos do projeto Planejamento da aquisição Visto em Visto em Mapa do projeto (EAP) Visto em Mapa do produto Visto em Plano de gerenciamento da qualidade Visto em Cronograma Visto em Relação das partes interessadas do projeto Plano de gerenciamento dos riscos Visto em Visto em Visão da equipe Visto em Como fazer? Planejar a relação das partes interessadas Negociador O negociador receberá de seus antecessores como equipe de planejamento ou outros negociadores a relação das partes interessadas com seu histórico de interesses e influências. Após o recebimento o negociador se tornará o responsável por este documento e assim o manterá sempre atualizado. Conscientização sobre a importância da comunicação. Gerente do projeto O gerente do projeto pode considerar que a equipe necessita de uma conscientização sobre a gestão da informação ou somente relembra-los sobre sua importância. Esta conscientização pode ser iniciada com a introdução de conceitos básicos de comunicação como: emissor, receptor, ruídos, barreiras de comunicação, se estendendo com apresentações de casos de sucesso e insucesso de

123 Planejar a comunicação (P.8) projetos anteriores ou até de projetos externos a empresa. Estatísticas de falhas de projetos por conta de problemas em comunicação e os principais problemas de comunicação em projetos são informações base para a conscientização. Outro ponto é alinhar os objetivos das partes interessadas aos objetivos estratégicos da organização. É interessante relembrar as ferramentas de comunicação utilizadas pela empresa e também quando e como utilizá-las. Planejar a distribuição das informações Negociador Utilizando a lista das partes interessadas são listados os receptores e emissores das informações do projeto. Um projeto tende a gerar documentos como exemplo resultados dos processos de planejamento e acompanhamento e os projetos geralmente possuem fases intermediárias de entrega, algumas destas entregas são apresentadas a demais partes interessadas e, para tanto, um meio de comunicação como exemplo ou reunião, deve ser previsto. Os meios de comunicação variam de acordo com o grau de envolvimento da parte interessada. Uma forma de identificar o grau de envolvimento é analisar qual o grau de impacto, ou seja, qual a profundidade de mudança que o projeto impactará na parte interessada, como demonstrada no gráfico a seguir: Tabela X: Análise de partes interessadas para um projeto (exemplo) Fonte: CHAVES, 2010, p.60. XAVIER (2009, p. 78) diz que para planejar a distribuição das informações, deve ser estabelecido o método ou a tecnologia de comunicação adequada para cada parte interessada. Uma vez definidas quais serão as informações a serem distribuídas, deve ser estabelecido quem será o responsável pela sua produção e qual a periodicidade da mesma. Com estas informações deve ser produzido um mapa das comunicações contendo: as partes interessadas, o assunto da informação, o documento, o meio, as ações esperadas e o responsável pela emissão, representado na tabela abaixo: Parte interessada (destinatário) Assunto da informação Stakeholder 1 Fases do projeto Documentos relacionados Mapa projeto do Meio Frequência Ação esperada Responsável (emissor) Única o que o destinatário tem que fazer assim que receber a Nome da pessoa que deve emitir ou mesmo o gerente do

124 124 Stakeholder 2 Validar entrega Planejar a comunicação (P.8) Checklist da qualidade Reunião Semanal informação projeto Tabela X: Exemplo de um mapa de comunicação Fonte: o autor. Para tornar o mapa de comunicação mais completo o negociador pode contar com a equipe do projeto e também com o suporte do gerente de projetos. A equipe do projeto participa também na distribuição de responsabilidades. O planejamento dos riscos e da qualidade, assim como os mapas do projeto e do produto são utilizados na elaboração do mapa de comunicação. O planejamento da aquisição é utilizado para pensar na comunicação com membros da equipe que trabalham externamente ao projeto. As principais datas de entrega (definidas pelo negociador) do mapa de comunicação são registradas em programas de calendário (ex: outlook ou google calendar) de modo que a equipe seja avisada automaticamente sobre os deadline. Geralmente, com o tempo, as empresas costumam criar um modelo de mapa de comunicação que é similar em todos os projetos, tendo pouca variação entre eles e causando agilidade no processo. Criar o cronograma macro Negociador Geralmente as partes interessadas externas a organização possuem responsabilidades que impactam diretamente no sucesso do projeto como aprovações, aceitações, disponibilização de informações, disponibilização de recursos entre outros. Tais responsabilidades precisam estar organizadas e integradas com o cronograma do projeto, de modo que se atrasarem eles saibam que o projeto poderá também sofrer atraso. Acrescido a isto existem as informações do mapa de comunicação criado anteriormente que também possuem datas de disponibilização. É interessante que todas estas informações estejam organizadas em formato cronológico e de fácil visualização. Este é o papel do cronograma macro. Nele também constam as principais entregas do projeto como visto no exemplo abaixo. Tabela X: Exemplo de um cronograma macro Fonte: o autor. As principais datas de entrega (definidas pelo negociador) são registradas em programas de calendário (ex: outlook ou google calendar) de modo que a equipe seja avisada automaticamente sobre os deadline. Geralmente, com o tempo, as empresas costumam criar um modelo de cronograma macro que é similar em todos

125 Planejar a comunicação (P.8) os projetos, tendo pouca variação entre eles e causando agilidade no processo. Distribuir responsabilidades da comunicação Equipe do projeto O negociador tem como responsabilidade incentivar para que todos da equipe do projeto participem do processo. O negociador fez o trabalho grosso que é o de gerar a maior parte do mapa de comunicação e também o cronograma macro do projeto, a próxima tarefa é da equipe que definirá, para as que estiverem em branco, quem será o responsável por criar as ferramentas de comunicação e apresentar as entregas. O resultado da distribuição é um documento, preenchido por um membro selecionado pelo negociador ou líder, distribuindo as responsabilidades aos membros da equipe. Outra tarefa da equipe do projeto é detectar, dentre suas responsabilidades atuais, quais podem entrar no mapa de comunicação. Verificação Revisar o planejamento da comunicação Equipe do projeto Tanto a equipe do projeto quanto o líder revisam o planejamento da comunicação tanto para auxiliar na qualidade quanto para entenderem e assim ajudarem na execução. É recomendável que eles participem de partes deste planejamento. Pode ser interessante também que tanto a equipe de planejamento quanto a equipe de orçamentos também revisem o planejamento. Validar planejamento da comunicação Gerente de projetos O gerente de projetos utilizará seus conhecimentos e visão estratégica para dar suporte ao negociador. O gerente de projetos tem que validar a qualidade do material e treinar o negociador para melhorar se este for o caso. Resultados Mapa de comunicação Cronograma macro Relação das partes interessadas atualizada Cronograma atualizado Visão de equipe atualizada Calendário do projeto O negociador irá inserir neste documento, privado, suas opiniões e considerações. A comunicação tende a gerar novas tarefas e restrições ao projeto, alterando assim o cronograma. Atualizar as regras com a distribuição das responsabilidades Registro das principais datas de entrega do projeto de modo que o calendário avise automaticamente as pessoas e também permita uma visão cronológica das entregas.

126 Organizar responsabilidades e plano do projeto Organizar responsabilidades e plano do projeto (P.9) O objetivo deste processo é organizar e disponibilizar para divulgação as responsabilidades do projeto, tanto para a equipe quanto para as partes interessadas. Também agrupa todo organiza o plano do projeto, ou seja, agrupa todo o planejado em um único documento. Entrada Planejamento da aquisição Plano de gerenciamento da qualidade Visto em Visto em Cronograma Visto em Relação das partes interessadas do projeto Plano de gerenciamento dos riscos Visto em Visto em Mapa da comunicação Visto em Visão da equipe Visto em Como fazer? Agrupar ações no plano de ação do projeto Líder O objetivo é agrupar os planos de ação identificados nas regras da visão da equipe, resultados do planejamento da qualidade, dos riscos e da comunicação, e salvá-las no formato 5w1h. A listagem deve ser agrupada por ordem cronológica e/ou por recursos, permitindo que todos possam acompanhar facilmente suas responsabilidades. O plano de ação do projeto é uma lista com todas as ações preventivas do projeto para que a equipe atinja a qualidade, com redução de riscos e com boa comunicação. Neste momento o líder, junto com a equipe do projeto, podem levantar as ações que exigem serem comunicadas e assim enviar ao negociador para que ele possa atualizar o mapa de comunicação. Deve estar visível e acessível a todos! O resultado é um plano de ação do projeto semelhante a tabela abaixo. O quê? Por quê? Quem? Onde? Quando? Como? Nome da ação Qual o motivo de existência da ação Responsável Qual local de impacto no projeto Qual momento do projeto Explicação de como será feita Tabela X: Exemplo de um plano de ação do projeto Fonte: o autor. Para reduzir o excesso de necessidade de manutenção deste documento, e recomendável que o quando não seja preenchido com datas e sim com eventos de gatilhos como, por exemplo, assim que a entrega X for realizada.

127 Organizar responsabilidades e plano do projeto (P.9) Criar matriz de responsabilidades Negociador De acordo com o PMI (2008, p. 185) uma matriz de responsabilidade é usada para ilustrar as conexões entre os pacotes de trabalho ou atividades e os membros da equipe do projeto. Uma forma de criar a matriz é pelo gráfico RACI (Responsible, Accountable, Consult and Inform [Responsável pela execução, Responsável pela aprovação, é Consultado e Informado]), como demonstrado na tabela abaixo. RACI Pessoas Atividade Ana Benjamin Carlos Dina Marcos Definição A R I I I Design I A R C C Desenvolvimento I A R C C Testes A I I R I R = Responsible, A = Accountable, C = Consult, I = Inform Tabela X: Matriz de responsabilidade usando um formato RACI Fonte: Adaptado de PMI (2008, p. 186). Ao fim chega a uma lista de responsabilidades do projeto, principalmente aquelas que possuem interações com as partes interessadas externas, informando, para cada atividade, quem executará, quem aprovará, quem será consultado e quem será informado. O cronograma macro é uma fonte para esta matriz que ilustra em outra forma de visualização e também com novos responsáveis e responsabilidades. A matriz de responsabilidades é uma grande ferramenta de comunicação, mas não precisa ser criada em todos os projetos ficando esta decisão a cargo do negociador. Criar o plano de desenvolvimento do projeto Gerente de projetos A equipe do projeto e também o gerente do projeto deve juntar toda a documentação de planejamento em um plano e verificar a consistência entre estes documentos. Por exemplo, se alguma resposta aos riscos foi planejada ela deve estar refletida na EAP e/ou cronograma e/ou orçamento (XAVIER, 2009, p. 111). O gerente de projetos agrupa o planejamento público feito até o momento em um único documento. Neste plano de divulgação criado com suporte do negociador e do líder deve conter: 1. Proposta aprovada do projeto; 2. Mapa do projeto (EAP); 3. Mapa do produto; 4. Plano de gerenciamento da qualidade; 5. Objetivo do projeto; 6. Plano de gerenciamento dos riscos; 7. Planejamento de aquisições; 8. Modificações propostas para o projeto; 9. Mapa de comunicação; 10. Cronograma macro; 11. Matriz de responsabilidade; 12. Visão da equipe; 13. Plano de ação do projeto. Este plano de desenvolvimento do projeto deve ser distribuído para todas as partes interessadas do projeto, antes

128 128 das reuniões que estão por vir Organizar responsabilidades e plano do projeto (P.9) Verificação Validar as responsabilidades internas Equipe do projeto A equipe do projeto valida se o plano de ação do projeto e também a matriz de responsabilidade estão corretamente formados e preenchidos. Validar as responsabilidades externas Equipe do cliente A equipe do cliente valida se a matriz de responsabilidade está formada e preenchida de acordo com suas necessidades. Esta validação é feita no processo Stakeholders participarem do planejamento. Revisar o plano do projeto Equipe do projeto Equipe do projeto revisa o documento final que representa todo o planejamento do projeto. Resultados Matriz de responsabilidade Plano de ação do projeto Visão da equipe atualizada Calendário do projeto atualizado Plano de desenvolvimento do projeto Documento com a lista de responsabilidades do projeto, principalmente aquelas que possuem interações com as partes interessadas, informando, para cada atividade, quem executará, quem aprovará, quem será consultado e quem será informado. Documento que lista todas as ações preventivas do projeto para que a equipe atinja a qualidade, com redução de riscos e com boa comunicação. O plano de ações do projeto substitui as regras previamente levantadas na visão da equipe, de forma organizada. O plano de ação do projeto possui datas de execução e as ações consideradas mais críticas pelo líder devem estar no calendário. Documento agrupando todo o planejamento público do projeto Stakeholders participarem do planejamento Stakeholders participarem do planejamento (P.10)

129 Stakeholders participarem do planejamento (P.10) O conceito deste processo foi fundamentado em 2.7, e O objetivo deste processo é alinhar as expectativas da equipe do projeto com as partes interessadas, e também comunicar com eficiência o processo e o planejamento para as partes interessadas. Entrada Plano de gerenciamento da qualidade Visto em Cronograma Visto em Plano de gerenciamento dos riscos Visto em Cronograma macro Visto em Matriz de responsabilidade Visto em Visão da equipe Visto em Proposta Visto em Mapa do projeto (EAP) Visto em Mapa do produto Visto em Propostas de modificações no projeto. Plano de desenvolvimento do projeto Visto em , e Visto em Como fazer? Organizar as modificações propostas para o projeto Gerente do projeto O gerente de projetos trabalha em cima do documento de propostas de modificações no projeto atribuindo argumentos para cada pedido de modificação, revisando prazos, custos e necessidade. Estas propostas podem alterar o plano de desenvolvimento do projeto. Preparar reunião de start Negociador O negociador cria uma apresentação para a reunião que será realizada com o cliente apresentando o plano de desenvolvimento do projeto e também os processos da empresa. Apesar de todos os documentos serem apresentados, a reunião deve destacar alguns pontos chave de discussão,

130 Stakeholders participarem do planejamento (P.10) como pontos críticos da proposta, dos mapas, da qualidade, dos riscos e também das responsabilidades. O negociador deve reservar na apresentação uma área para apresentar as modificações propostas para o projeto, descobertas até o momento pela equipe do projeto, com o intuito de reduzir os riscos e de ampliar a qualidade. Para isso, o negociador pode contar com o suporte da equipe do projeto e também do gerente de projeto. Executar reunião de start do projeto Negociador Nesta reunião as principais partes interessadas do projeto devem participar destacando a equipe do projeto e a equipe do cliente. O negociador é o responsável por conduzir a reunião e provocar discussões em pontos chave fixando o conhecimento do planejamento. Cada ponto discutido tende a gerar alterações, que podem causar impactos em prazos e custos, o que deve estar claro para todos. O ideal, mas não obrigatório, é que cada pacote de trabalho do mapa do projeto e que cada parte do mapa do produto possua custos e prazos visualizáveis e que cada um destes blocos seja explicado e eventualmente debatido. A qualidade e a visão de equipe devem ser alinhadas com as expectativas da equipe do projeto. Alguns riscos e aquisições são apresentados e debatidos. O negociador tem que deixar o mapa de comunicação, o cronograma macro e a matriz de responsabilidade bem entendidos e fixados em todos. Geralmente esta reunião gera diversas pontas soltas e cria uma sensação de caos no planejamento devido as diversas modificações solicitadas. Mas todos devem ficar calmos e registrar todos os pedidos e decisões em uma ata de reunião. Ao fim, o negociador resume todas as decisões da reunião, lendo-as em voz alta e solicitando a confirmação de entendimento de todos. Priorizar entregas na reunião de start Negociador Fundamentado em Com o mapa do produto aberto, o cliente aponta as partes e subpartes do produto que, para ele, são mais importantes e também as que desejariam que fossem entregues com antecedência, podendo então existir duas métricas como grau de importância e grau de urgência, ou unificando estas duas métricas em uma única chamada prioridade. Esta priorização é numérica e para cada subparte do mapa do produto, o negociador deve inserir um número correspondente à ordem de priorização. A equipe costuma identificar alguns bloqueios técnicos neste momento, tornando a priorização mais exequível. As partes interessadas devem estar avisadas que a priorização não significa que a equipe entregará partes do projeto com antecedência, e sim auxiliará no esforço do grupo e também na comunicação deixando claro para todos quais partes são as mais importantes do projeto e que precisam estar com maior qualidade. A equipe do projeto fará um planejamento posterior, podendo sim, decidirem em realizar sub entregas do projeto, dependendo do tamanho do projeto, da complexidade da funcionalidade, das limitações técnicas ou da necessidade de comunicação. Técnica de priorização de Kano Caso o negociador sinta que técnica anterior não surtirá resultado, como por exemplo, quando o cliente julga que tudo é prioridade, ou quando o projeto exige que faça uma pesquisa com diversas partes interessadas para descobrir dentre os requisitos existentes o que é indispensável, importante ou desejado no projeto, recomenda-se o uso da técnica de Kano. Para isso, o negociador e o líder devem agrupar requisitos e/ou funcionalidades presentes nos mapas do projeto e

131 Stakeholders participarem do planejamento (P.10) do produto em entregáveis e criar, para cada, as seguintes duas perguntas (adaptado de ASFORA, 2009, p. 70): 1. Se a próxima versão do produto [Nome do produto] incluir [a/o] [Nome do requisito ou descrição], como você se sentirá? 2. Se a próxima versão do produto [Nome do produto] NÃO incluir [a/o] [Nome do requisito ou descrição], como você se sentirá? E para cada pergunta permitir as seguintes respostas: Imagem X: Lista de opções de respostas Fonte: ASFORA (2009, p. 70). Para cada parte interessada e suas respostas da pergunta positiva e negativa aplicar o quadro abaixo e assim identificar a categoria da prioridade, se para esta pessoa a entrega é indispensável, importante ou desejada: Figura X: Respostas às perguntas funcionais, disfuncionais e resultados para cada combinação. Fonte: ASFORA, 2009, p. 64. Finalizada a pesquisa as respostas devem ser agrupadas por entrega e calculada a porcentagem por categoria de prioridade como exemplificado na tabela abaixo: Tema D L M I R Q Classificação Requisito 1 18,4 43,8 22,8 12,8 1,7 0,5 Linear Requisito 2 8,3 30,9 54,3 4,2 1,4 0,9 Mandatório Requisito 3 39,1 14,8 36,6 8,2 0,2 1,1 Desejado e mandatório Tabela X: Sumarização dos resultados. Fonte: ASFORA, 2009, p. 64. Pode parecer trabalhoso, mas uma planilha eletrônica gera esta tabela automaticamente. Alguns indicadores importantes para serem avaliados são (ASFORA, 2009, p. 72): O grau de rejeição daquele requisito. Isso indica que além de não deixar o usuário satisfeito, ainda deixa ele descontente, caso o requisito seja implementado. O número de indiferente elevado leva a mostrar que aquele requisito não tem uma importância de ser implementado tão grande, o que indica que ele ou não foi bem pensado, ou o usuário não entendeu o que

132 Stakeholders participarem do planejamento (P.10) ele faria ou se realmente nesse momento ele deve ficar de lado. Um número grande de mandatório aliado com alguma quantidade de Desejado e ou importante, indica que aquele requisito é mandatório para alguns e também tem importância para outros. Dentro dessas avaliações deve-se até descartar respostas pouco expressivas que indiquem que o usuário não entendeu a resposta ou até mesmo é apenas contra aquela ideia. Atualizar planejamento pós reunião de start Negociador Tanto o negociador quanto o líder, com suporte do gerente de projeto, revisarão todos os processos citados até o momento, alterando-os de acordo com as decisões da reunião. A equipe do projeto deve entender as alterações no plano, e dependendo do grau de mudança, alguns processos do planejamento devem ser refeitos. Uma nova proposta será gerada para o projeto, incluindo todo o planejamento feito até o momento. Possivelmente existirão alterações em prazos e custos e assim uma nova aprovação torna-se necessária. Existe a possibilidade de trocas de atividades, onde algumas que possuem pouco valor agregado são substituídas por outras que possuem grande valor agregado, reduzindo ou anulando impactos em custos. Dependendo do caso, para evitar atrasos com renegociação, o projeto pode ser revisto prevendo divisão em fases, onde partes do projeto mais impactadas ficam em um segundo momento e assim sua execução pode ser iniciada em paralelo. Verificação Validar o planejamento do projeto Equipe do projeto A equipe do projeto valida se as alterações ocorridas no planejamento do projeto condizem com a exequibilidade técnica. Aprovar o planejamento do projeto Equipe do cliente A equipe do cliente aprova o plano do projeto e permite que ele seja executado. A não aprovação acarretará o andamento impactando no prazo do projeto. Resultados Relação das partes interessadas do projeto atualizada Processos de iniciação e planejamento atualizados Entregas do projeto priorizadas Plano de desenvolvimento do projeto atualizado Novas percepções referentes as partes interessadas são levantadas e, portanto, o negociador pode atualizar o documento. Além disso, são levantados diversos novos requisitos que devem ser registrados. Este processo tende a causar alterações em todos os processos vistos até o momento. Portanto, estes devem ser atualizados. Lista de partes e subpartes do produto devidamente priorizadas pelos responsáveis do negócio. Alterações no plano de desenvolvimento do projeto que refletem o alinhamento do planejado com os desejos, necessidades e expectativas das partes interessadas.

133 Execução O Grupo de Processos de Execução consiste nos processos realizados para concluir o trabalho definido no plano de gerenciamento do projeto de forma a cumprir as especificações do projeto. Este grupo de processos envolve coordenar pessoas e recursos e também integrar e executar as atividades do projeto em conformidade com o plano de gerenciamento do mesmo (PMI, 2008, p. 54). O grupo de processos de execução organizam os processos conforme demonstrado na imagem abaixo. Imagem X: Processos da execução. Fonte: o autor. Os tópicos abaixo descrevem detalhadamente cada um destes processos Criar protótipo e design do produto Criar protótipo e design do produto (E.1)

134 Criar protótipo e design do produto (E.1) Criar design e/ou protótipo do produto alinhando a comunicação do escopo, ou seja, do que será produzido. Entrada Mapa do projeto Mapa do produto Como fazer? Briefing visual Negociador Caso o projeto exija a criação de layouts e design criativo na formação do produto é necessário que seja levantado o briefing visual. Freehand Equipe do projeto Criar o protótipo do produto Equipe do projeto (designer) ASFORA (2009) Possibilitando uma avaliação mais rica dos requisitos do sistema. Além disso, os protótipos contribuem para um maior envolvimento entre as partes interessadas durante as atividades de elicitação, análise e negociação de requisitos; [sistema web] a equipe de projeto desenvolve alguns protótipos para validar a arquitetura, obter familiaridade com a tecnologia, validar idéias, mitigar riscos e avaliar viabilidade. Dependendo do porte do projeto, a duração desta fase pode varia de semanas a meses. é criada de validada através de um protótipo navegável que evolui para a solução final. trata-se, portanto, de um protótipo evolutivo criação conjunta pela equipe de criação e pela equipe cliente de alguns artefatos que resultam, naturalmente, no protótipo navegável, garantindo um processo de aprovação mais rápido e tranquilo. Também conhecidos como wireframes, descerevem a estrutura de conteúdo de uma página web sem levar em consideração os detalhes visuais dos mesmos. Seu objetivo é apresentar através de um modelo simples, a organização geral dos conteúdos da página, suas estruturas de navegação e principais áreas. Os modelos de grade representam, portanto, o modelo estrutural e navegacional do SW, mostrando onde cada conteúdo se encaixa e os principais padrões de usabilidade utilizados [GRAHAM, 2003]. Criar o design do produto Equipe do projeto (designer) Utilizando o mapa do produto e as atividades do cronograma. Verificação Alinhar criação Equipe do projeto ddd. Aprovar criação Equipe do cliente

135 Criar protótipo e design do produto (E.1) dsfdf. Resultados Proposta Documento descrevendo o objetivo, a necessidade do projeto, o escopo, prazo estimado, orçamento, restrições e premissas Equipe formar o Kanban com entregas semanais Equipe formar o Kanban com entregas semanais (E.2)

136 Equipe formar o Kanban com entregas semanais (E.2) O conceito deste processo foi fundamentado em 2.7 e 2.8. Fornecer a visibilidade para todos sobre o desempenho e acompanhamento do projeto. Divulgar o cronograma no conceito de gestão a vista. Entrada Cronograma Mapa do produto e Mapa do projeto. Planejamento dos riscos e da qualidade Entregas do projeto priorizadas Visto em Lista de atividades sequenciadas com os tipos de recursos atribuídos. O cronograma é a base para a formação do kanban e garante que o estimado não seja esquecido. Visto em e Utilizado para facilitar a identificação dos entregáveis e agrupar as atividades do cronograma. Visto em e Estes planejamentos são utilizados como referência identificar observações das entregas. Estas observações são anotadas nos cartões kanban, neste momento ou nas reuniões semanais, fazendo com que o planejamento não seja esquecido. Dependendo dos riscos, o prazo previsto das entregas, ou o como fazer será discutido. Visto em A priorização ditada pelo cliente é importante para conduzir o trabalho da equipe que deve tentar entregar primeiramente o que é mais prioritário, e isto deve estar refletido no kanban. As prioridades também ajudam na identificação das entregas. Como fazer? Identificar entregas Líder Utilizando o mapa do produto, mapa do projeto e as atividades do cronograma, anotar os grupos de atividades em um local visível para todos. Grupos de atividades são entregáveis do mapa do projeto, ou partes e/ou subpartes do mapa do produto, que duram até três dias (consultando o cronograma), caso tiver maior duração este grupo deve ser dividido. As priorizações ditadas pelo cliente devem ser utilizadas na identificação das entregas. Os grupos de atividades listados representam uma entrega completa que permita ser inspecionada, validada e testada, como exemplo, em um projeto de software, um sistema de login, que quando pronto, permite que o controlador da qualidade faça testes. Toda a equipe do projeto deve participar, e todos devem concordar que o grupo de atividades em questão representa uma entrega, o que não é uma tarefa difícil, sendo que o planejamento já está feito. Se a entrega identificada tiver uma duração muito pequena, é recomendável agrupá-la com outra entrega. Para cada entrega são preenchidos seus atributos, como: Prioridade já ditada pelo cliente; Tempo de trabalho previsto no cronograma; Responsável pela execução (a ser definido); Semana da entrega (a ser definida); Tempo realizado (a ser definido); Para cada entrega, buscar no cronograma existente e, possivelmente, também na análise de riscos a duração em horas desta entrega, e buscar no documento entregas do projeto priorizadas o desejo de priorização

137 137 informado pelo cliente Equipe formar o Kanban com entregas semanais (E.2) Se o projeto for muito extenso, o ideal que já tenha sido dividido em fases, caso contrário, que seja dividido em fases de no máximo dois meses. É muito importante que este processo liste somente as entregas da fase em questão, ou seja, as entregas de uma fase de no máximo dois meses. Definir responsável pela entrega no kanban Equipe do projeto As tarefas já possuem em seus registros o tipo do profissional que irá executá-las (ver estimar tempo), portanto, a tarefa agora é, dentro do tipo do profissional, descobrir quem da equipe será o responsável por qual entrega. Para isto, em cada entrega, um membro da equipe deve se responsabilizar. O trabalho consiste em anotar o nome do responsável na frente da entrega até que todas tenham um responsável. Feito este trabalho, a tarefa agora é balancear o trabalho, para o caso de existir pessoas com mais tarefas que outras, redistribuindo entregas entre todos até que fiquem com carga semelhante de horas. Claro que, se um profissional for trabalhar no projeto por menos horas, este fato deve ser levado em consideração na distribuição de horas. O líder é o condutor desta reunião. Distribuir kanban em entregas semanais Equipe do projeto Tendo como base a lista de prioridades desejadas pelo cliente, o planejamento de riscos e a duração da tarefa, definir quais entregas serão feitas em qual semana. Cada profissional dita quais de suas entregas serão feitas na semana 1 (S1), depois quais serão feitas na semana 2 (S2) e assim por diante até completar toda a fase, ou todo o projeto. Por fim, cada profissional fica com aproximadamente 30 horas de tarefas por semana (30 horas é para exemplificar, sendo que o gerente de projetos pode definir o número semanal de horas). No quadro visível a todos estarão listadas todas as entregas da fase, de forma semelhante a tabela abaixo: Entrega Prioridade cliente Tempo previsto Responsável Semana Ex: Treinamento horas Fulano S7 Ex: Login 2 12 horas Ciclano S1 Tabela X: Exemplo de distribuição de entregas Fonte: o autor. As entregas em formato semanal são muito importantes para comunicar o desempenho, já que todos conseguem perceber individualmente e semanalmente se há atraso no projeto. Criar Kanban Líder O líder pode indicar uma pessoa, ou ele mesmo, quem irá anotar os cartões ou postit com as entregas e seus atributos como: título, prioridade cliente, tempo previsto, responsável e semana. Também adicionar ao cartão o tempo realizado, que será preenchido assim que a tarefa for finalizada e as observações como mudanças, riscos e qualidade. Com todas as entregas em mãos, formar um quadro, visível a todos, com os seguintes blocos de cartões: a fazer, fazendo, feito, validado. Todos os cartões anotados são colados/pregados no grupo a fazer, e o responsável quando for iniciar a tarefa deve arrastar o cartão que a representa para o grupo fazendo. Quando o profissional finalizar a entrega ele irá arrastar o cartão para feito e quando este tiver sua qualidade validada, ele irá arrastá-lo para

138 138 validado Equipe formar o Kanban com entregas semanais (E.2) Segue um exemplo de kanban feito digitalmente, sendo o recomendável fazê-lo em um quadro, off-line, visível a todos, permitindo a gestão a vista. Imagem X: Exemplo de Kanban Fonte: o autor. Verificação Revisar Kanban Equipe do projeto A revisão por parte da equipe, incluindo negociador e líder, consiste em garantir que todas as atividades da fase estejam na fila para serem produzidas. A equipe também valida que o planejado não atrase o projeto e, se for necessário atrasar, então devem planejar a comunicação e negociação com o cliente (ver distribuir as informações). A equipe também deve atualizar o kanban com informações sobre tempo real gasto, mudanças e o planejado para os riscos e qualidade (informações estas geralmente advindas no dia a dia e nas reuniões de acompanhamento semanais). Resultados Kanban Quadro visível a todos com as tarefas da fase agrupadas em: a fazer, fazendo, feito, validado Equipe gerenciar a execução Equipe gerenciar a execução (E.3)

139 Equipe gerenciar a execução (E.3) O conceito de distribuir informações foi fundamentado em 2.8. Este processo tem como objetivo fazer com que a equipe execute o planejamento do projeto. Assegurar a realização do trabalho no momento e na sequencia certas e também em coletar as informações sobre o progresso do trabalho. Para isto, possui checklist forçando buscar referências no planejamento e prevê visualização e atualização no kanban que solicita a coleta do progresso. Entrada Kanban Plano de desenvolvimento do projeto Ações preventivas e corretivas aprovadas Solicitações de mudanças aprovadas Plano de ação do projeto Visto em O kanban é utilizado como base para assegurar a realização do trabalho no momento e na sequencia certas e também para coletar o progresso. Permite a gestão à vista. Visto em Utilizado no checklist proposto que objetiva a consulta ao planejado antes de fazer qualquer tarefa. Visto em As ações corretivas e preventivas detectadas devem estar dispostas como observações nos cartões kanban, ou disponibilizadas no planejamento de modo que sejam consultadas antes de iniciar a tarefa em questão e que não sejam esquecidas. Visto em As mudanças geralmente se transformam em uma entrega, que é um cartão no kanban. Caso contrário, devem estar dispostas como observações nos cartões kanban, ou disponibilizadas no planejamento de modo que sejam consultadas antes de iniciar a tarefa em questão e que não sejam esquecidas. Visto em O plano de ação do projeto possui datas e ações que devem ser lembradas e executadas conforme planejadas garantido qualidade, gerenciando riscos e preocupando com a comunicação do projeto. Como fazer? Ao iniciar uma tarefa Equipe do projeto Antes de iniciar uma entrega, ou seja, assim que arrastar um cartão no Kanban para o grupo Fazendo, o profissional deve executar o checklist a seguir: Relembrar o objetivo do projeto. Relembrar a visão da equipe. O que diz no mapa do produto ou mapa do projeto sobre esta entrega? O que diz na proposta, no escopo e quais são as premissas? Existe algum equipamento, material ou terceiro que irá me ajudar nesta entrega? Relembrar a qualidade do projeto. Existe algum plano de qualidade referente a esta entrega? Relembrar os riscos do projeto. Existe algum risco referente a esta entrega? Relembrar o plano de comunicação. Esta entrega exige alguma comunicação com os clientes?

140 Equipe gerenciar a execução (E.3) Existe algum plano de ação, ou responsabilidade, que impacta ou é impactada por esta entrega? Como funciona esta tarefa no protótipo ou design (caso não for o processo em questão)? Existe alguma mudança ou ações corretivo-preventivas para esta entrega? Como farei esta entrega? Tenho dúvidas quanto a esta entrega? Quanto tempo tem para realizar esta entrega? Apesar de serem muitas questões, existe neste caso a curva de aprendizado, onde diversas destas questões estarão tacitamente respondidas em tarefas posteriores, por terem suas respostas pouco mutáveis. Outras questões variam de tarefa por tarefa, e estas devem estar adequadamente respondidas antes de iniciar o trabalho. Estas dúvidas nem sempre são respondidas na reunião semanal (ver controlar o andamento do projeto), por isso, é necessário conversar com o líder, negociador e/ou com o cliente. O não entendimento completo da entrega faz com quê o profissional pule para outra tarefa enquanto as questões estão sendo, ou serão debatidas. Atualizar o kanban Equipe do projeto Equipe arrastar os cartões de A fazer para Fazendo e deste para Feito. Esta atualização é realizada toda vez que um profissional iniciar e finalizar uma entrega permitindo que todos vejam o andamento do projeto. Se no decorrer do trabalho forem detectadas necessidades de mudanças e/ou ações corretivas e preventivas, novos cartões (preferencialmente de outra cor) são criados e agrupados por cima do cartão corrente. Mudanças extensas, complexas ou impactantes devem executar o processo equipe gerenciar mudanças. Coletar progresso Equipe do projeto Os cartões que forem arrastados para o grupo Feito são atualizados com, no mínimo, a informação do tempo real de duração. Por exemplo: se foi planejado que uma tarefa dure 12 horas e o profissional gastou 8 horas, estas 8 horas devem ser registradas no cartão. Além disso, existem as informações de custos adicionais, ações corretivas e preventivas e necessidades de mudanças que, como dito no item anterior, são descritos em outros cartões e agrupados ao atual. Pode acontecer de alterar o início da tarefa que iria ser feita na semana atual, e ela ir para outra semana, a razão disto também deve ser registrada em um campo chamado data real de início. Executar o plano de ação do projeto Equipe do projeto O plano de ação do projeto possui diversas atividades que devem ser executadas em uma determinada data promovendo garantia da qualidade, mitigação ou aproveitamento dos riscos e prevenção de uma boa comunicação. Cada membro deve cuidar das suas responsabilidades podendo inclusive cadastrar as datas em um calendário para serem lembrados. Verificação Incentivar atualização kanban e progresso Líder O líder deve incentivar para que todos atualizem os cartões e o gerente de projetos também pode ajuda-lo nesta tarefa. Auditorias de qualidade e cumprimento do processo são previstas em garantir a qualidade.

141 Equipe gerenciar a execução (E.3) Este incentivo pode ser feito promovendo uma brincadeira, como exemplo, quem não atualizar então deve depositar uma moeda em um cofre e este dinheiro será utilizado por todos. Esta decisão se haverá uma representação fica por conta do líder e da equipe do projeto. Resultados Kanban atualizado Entregas atualizadas nos devidos grupos: fazendo ou feito. E os cartões destes grupos com informações registradas sobre: duração real, necessidades de mudanças, ações corretivas e preventivas, custos incorridos e data real de início. A equipe deve sempre manter o kanban atualizado Distribuir as informações Distribuir as informações (E.4)

142 Distribuir as informações (E.4) O conceito de distribuir informações foi fundamentado em 2.4 e Processo para a divulgação das informações conforme planejado ou quando oportuno. Este processo também trata do armazenamento das informações e de planejamento das negociações. Entrada Mapa de comunicação Cronograma macro Matriz de responsabilidade Plano de ação do projeto Relação das partes interessadas Visto em O mapa de comunicação possui uma lista das principais comunicações do projeto prevendo data, mídia (formato da comunicação), emissor e receptor. Ele é a base, planejada, da distribuição das informações. Visto em O cronograma macro possui as principais datas de entrega do projeto. Ou seja, nele estão as datas de entrega esperadas pelas partes interessadas. Sua alteração exige uma comunicação com os clientes. Visto em Um documento com as principais responsabilidades das partes interessadas. Ele é utilizado como referência ao solicitar uma responsabilidade de um cliente. Como foi combinado no início, ele ajuda na comunicação, na lembrança e na resolução de conflitos. Visto em O principal documento utilizado pela equipe para lembrar suas responsabilidades. O ideal é que este documento esteja atualizado com informações dos outros documentos, tornando-o central. Visto em Lista das partes interessadas com o grau de interesse e influência, e também com estratégias de comunicação. Ou seja, um documento central para o negociador, quando se trata da distribuição das informações. Como fazer? Gerenciar distribuição interna das informações Equipe do projeto A equipe do projeto possui diversas responsabilidades no projeto, e todas (ou quase todas) possuem entregáveis e datas. Cada qual deve cuidar das suas responsabilidades podendo inclusive cadastrar em um calendário para serem lembrados. Auto-organização esta fundamental para a qualidade da comunicação no projeto. Os documentos chave para a distribuição de comunicação são o mapa de comunicação e o cronograma. O mapa de comunicação possui receptores e emissores e os profissionais emissores devem estar cientes de seu papel. E o cronograma possui as entregas do projeto, no qual a equipe se esforça para manter sem atrasos. O plano de ação do projeto é um documento central com as responsabilidades da equipe e, se estiver corretamente integrado com o mapa de comunicação, seguindo-o, automaticamente o planejamento no mapa de comunicação será cumprido. A equipe do projeto é responsável por garantir que as informações internas sejam distribuídas com qualidade. Isso significa que cada um que executa uma tarefa deve detectar informações a serem compartilhadas para estas tarefas. E também garantir que quando, certo planejamento for executado, as principais informações também sejam compartilhadas. Lembrar das responsabilidades externas Negociador

143 Distribuir as informações (E.4) Todas as responsabilidades externas, ou seja, dos clientes e outras partes interessadas, são organizadas pelo negociador. Ele tem o papel de lembrar e cobrar os retornos das partes interessadas. Caso estes atrasem, o negociador pode solicitar uma reunião com a equipe do projeto, ou somente o líder, para levantar os impactos que este atraso causa no projeto, identificando impactos em prazo e levantando argumentos. O negociador não consegue e nem pode garantir as entregas de tais pendências, sendo esta responsabilidade de um determinado cliente ou outra parte interessada externa. Os principais documentos usados nesta parte são o mapa de comunicação, a matriz de responsabilidades e o cronograma macro. Distribuindo informações Negociador Quando se trata de distribuição externa da informação o negociador é o centro da comunicação do projeto, já que ele recebe informações dos clientes para serem distribuídas para a equipe e também recebe informações da equipe do projeto para serem distribuídas para o cliente. O mapa de comunicação diz em qual meio será feita a distribuição da informação como exemplo , telefone e reunião. Fica a cargo de o negociador seguir o planejado (ou alterá-lo) e marcar as reuniões, ou outros meios, com todos os envolvidos no momento certo. Além do mapa de comunicação, existem a matriz de responsabilidade, o cronograma macro e o plano de ação do projeto, que devem estar integrados com o mapa de comunicação, mas em todo caso vale a pena revisá-los, pois cada qual possuem entregas que podem gerar distribuição externa de informações. O negociador irá decidir o melhor meio a usar registrando no mapa de comunicação. Além do planejado, é comum, surgirem novas e importantes comunicações no decorrer do projeto, e o negociador deve utilizar o momento mais oportuno para comunicar, para tanto, talvez seja necessário realizar um planejamento de argumentos e do melhor meio de comunicação, adicionando esta nova necessidade no mapa de comunicação. De acordo com XAVIER (2009, p. 118) as informações sobre o projeto podem ser distribuídas utilizando uma variedade de métodos, incluindo reuniões do projeto, distribuição de documentos impressos, acesso compartilhado a base de dados eletrônicos, fax, correio eletrônico, correio de voz, videoconferência e intranet específica para o projeto. Dentre as várias formas de comunicação, as que mais têm resultados favoráveis são os contatos pessoais. XAVIER completa listando alguns aspectos importantes acerca das comunicações: O emissor é responsável por tornar a informação clara, sem ambiguidades e completa, para que o receptor possa recebê-la corretamente e confirmar que foi propriamente compreendida. O receptor é responsável por assegurar que a informação é recebida na sua totalidade e corretamente entendida. Nesta metodologia, para a comunicação interna durante a execução do projeto é prevista a socialização como principal meio as reuniões de acompanhamento e reuniões de impedimentos (remoção de barreiras). Claro que s e sistemas de gerenciamento são bem vindos e devem ser utilizados. Dicas para a distribuição das informações Ter em mente Excesso de informação pode ser prejudicial para os receptores ("obrigado pela informação que você não me deu"). Percepção seletiva: para a informação entrar no ouvido do receptor é importante descobrir o que lhe interessa (exemplo: mulher fica grávida começa a ver outras mulheres grávidas). Aprender a ler pessoas: ás vezes no a pessoa é agressiva, mas pessoalmente não.

144 144 Barreiras: Distribuir as informações (E.4) Falta de conhecimento do assunto gera barreiras à comunicação, então tem que mostrar domínio sobre o que fala; Se houver distância tem que agrupar a equipe ao menos uma vez; Fatores ambientais: calor, frio, ruídos; Se a atenção do receptor for caindo, tomar uma atitude como, por exemplo, pausa para água. Melhorar a eficácia da comunicação: Adequar a mensagem ao receptor; Feedback constante; Utilizar múltiplos canais; Ouvir X Escutar. Evitando rumores: Anuncie datas para decisões importantes; Explique decisões e comportamentos que gerem dúvida; Enfatize vantagens e desvantagens das decisões atuais e planos futuros; Discutir abertamente piores cenários - melhor que fantasias secretas; Gerenciar as partes interessadas: Argumentação e persuasão Supere o medo expor suas idéias o "Conhece-te a ti mesmo" Sócrates Quais as intenções: Persuadir, Entreter ou Informar? Definir argumentos: Recorra aos próprios conhecimentos sem censuras; Consulte internet, livros, filmes e jornais; Converse com especialistas e leigos; Concentre-se nos argumentos; Monte um repositório de informações; Conheça os ouvintes: Sobre s Qual a expectativa? Informação, curiosidade,...; Quanto conhece sobre o tema? Grau de aprofundamento...; O que o motiva? Sucesso profissional, dinheiro...; Qual o tipo predominante? Motivado, hostil, indiferente... Ao escrever um ou relatório: O emissor tende a escrever de maneira informal e o receptor a ler de maneira formal; Leia-o 2 vezes antes de enviar; Nunca assuma que o receptor estará otimista ou aderente a suas idéias; Jamais responda o no calor da ira" o Sugestão: clica em responder, apaga os destinatários, escrever o que está pensando, deixar descansar no rascunho, depois de horas ler e escrever um novo .

145 145 Sobre reuniões Distribuir as informações (E.4) Ter controle emocional. Saber o que vale a pena lutar. Ele deve ser R.I.C.O. o Relevante: o Ilustrativo: o Conclusivo o Objetivo Por que muitas reuniões são ineficientes? Falta de planejamento Não ser prolixo (falar demais e dizer pouco); "Das palavras as mais simples das mais simples as menores" Churchil; Procurar uma abordagem/metodologia simples; "Simples é a evolução do complexo" "A simplificação é a sofisticação máxima" (Leonardo da Vinci) Ilustrar é esclarecer. Ex: gráficos, tabelas, imagem, exemplos, metáforas... É começar do fim. Começar do mais geral e depois específico. Ex: imprensa. É ir direto ao ponto. O início do parágrafo tem que ter a informação principal (ler o texto 2 vezes). Não cumprimento da agenda proposta Não respeito aos horários de início e término Liderança ineficiente Indisciplina dos participantes É necessário fazer a gerência das reuniões: Antes (planejamento) o Se perguntar: reunião é o melhor canal? o Estabelecer o objetivo da reunião; o Definir uma agenda (pauta, local, data, horário de início/fim); o Selecionar os participantes e definir os documentos de apoio; Durante (execução) Com os documentos de apoio o pessoal adiciona valor a reunião. o Iniciar e terminar pontualmente; o Mantenha o foco nos objetivos; Estimule os participantes a opinar e saiba discordar (mesmo que seja um superior); o Resuma o que ficou decidido Depois (acompanhamento) Pedir para alguém fazer a ata durante com: o quê, quem, quando; o Elabore a ata e envie para todos os participantes; o Faça o acompanhamento de todas as tarefas distribuídas;

146 146 Sobre apresentações Distribuir as informações (E.4) Dica: ficar na cola somente do quando; É necessário organizar a argumentação (apresentação), mais ou menos da seguinte maneira: Introdução (15% do tempo): conquistar atenção. Antes de comprar, a ideia tem que te comprar. o Cumprimento aos ouvintes, contar uma história, fato. Levantar reflexão (quer saber como ganhar um milhão?); o Apresentar a utilidade do assunto; Preparação (10% do tempo): preparar o entendimento. o Qual é, e aonde quer chegar com o assunto? o Porque desenvolver o assunto? Exemplo: falar o que é o problema; o Principais tipos de narração; o Entendimento; Mostrar históricos, apresentar problema, apresentar solução de um problema; Exemplo: quais são as partes do assunto central - no máximo 3 ou 4 partes; Assunto central (65% do tempo): confirmar ou refutar a argumentação o Satisfação = percepção expectativa; o Se todos os argumentos são fracos então soltar todos de uma vez; o Se todos os argumentos são fortes então falar um a um; o Se os argumentos são fracos e fortes: um dos mais fortes primeiro, depois do mais fraco até o mais forte; Por exemplo, se tiver nove argumentos, então priorizar argumentos em uma lista, apresentar o segundo mais forte em primeiro, depois o mais fraco que é o nono, depois o oitavo, até chegar ao primeiro que é o mais forte atingindo a satisfação; Conclusão (10% do tempo): Levar à ação de acordo com seus argumentos o Anunciar que é a conclusão; o Levar as pessoas à ação; o Recapitular; o Epílogo: dirigido mais para o sentimento do que para a razão. Em uma apresentação de slides, cada um deve demorar em média 2 minutos, e ela deve durar em média 30 minutos. Planejando negociação Negociador Quando há mudanças no projeto, tanto ocorridas por pressão externa (exemplo: pedido de redução de prazo) quanto ocorridas por pressão interna (exemplo: atraso no prazo) o negociador se vê pressionado em solucionar, repassando ás vezes, esta pressão para o líder ou o próprio gerente de projetos que nem sempre possuem domínio da comunicação tomando decisões prejudiciais para alguma das partes. Em um relacionamento de longo prazo, uma negociação deve ser ganha-ganha, ou seja, as duas partes da negociação devem ganhar. Este ganho mútuo quase sempre é possível, sendo o sucesso ligado diretamente a variáveis como tempo, informações e soluções criativas. A equipe do projeto é formada pelos membros da equipe, líder e negociador, portanto todos são responsáveis

147 Distribuir as informações (E.4) diretamente pelo sucesso ou fracasso do projeto e devem criar juntas as melhores soluções para o problema. Ao mesmo tempo as pessoas não podem ser constantemente interrompidas de seu trabalho diário, pois isso acabará causando algum impacto negativo ao projeto. Por isso, o negociador pode marcar encontros periódicos com o restante da equipe (exemplo: semanal), e antes deste encontro ir armazenando em um único documento todas as negociações importantes, ou seja, não todas existentes e nem todos os s recebidos, mas as negociações que podem causar maior impacto ao projeto. É comum que vários destes encontros periódicos sejam cancelados por não ter tido nenhuma negociação do nível exigido. E o negociador tem como responsabilidade obter ao máximo as informações sobre o pedido. Não é objetivo de este artigo aprofundar em conhecimentos de negociação, mas recomenda-se que para as negociações mais importantes o checklist abaixo seja utilizado na reunião com os outros membros da equipe (o negociador já deve vir previamente preparado, para reduzir tempos gastos) (FILARDI, 2011, p. 11): Definição dos objetivos na negociação: o o o o Análise da situação o o o Estratégias o o o o o o o Objetivo principal; Objetivos secundários; Plano de ação a ser seguido; Definição do MAPAN (melhor alternativa para um acordo negociado), MACNA (melhor alternativa em caso de não acordo) e ZOPA (zona de possível acordo). Analisar sua posição perante o outro negociador e rever as informações (se for o caso); Ganhos e perdas que envolvem a negociação. Alternativas a usar; Priorizar os itens a discutir; Estratégias e táticas a serem empregadas (lembrar do relacionamento a longo prazo); Procurar identificar o estilo do outro; Avaliar os pontos favoráveis e desfavoráveis; Ambiente (local, estrutura); Simular a negociação; Reconhecer os pontos fortes e fracos; Levantar argumentos com o uso do PIP (problema, informação, plano); A negociação deve ser realizada com base em argumentos e com os sentimentos controlados. Para levantar os argumentos utiliza-se o PIP (problema, informação, plano), como demonstrado no exemplo abaixo.

148 Distribuir as informações (E.4) Imagem X: Exemplo de uso do PIP Fonte: TIE-Brasil, 2002, p. 13. Armazenando informações externas Negociador Quase todos os contatos das partes interessadas (exemplo: conversa informal, telefonema, , reunião) geralmente são desejos, necessidade ou expectativas e estes requisitos não podem ser perdidos e devem estar organizados, pois são responsáveis por diversas decisões e por moldar o produto. Portanto é recomendável que os requisitos sejam registrados na lista das partes interessadas, agrupados pelo emissor, para consultas posteriores e usado na defesa do resultado do produto. As requisições externas podem estar ligadas a lista das partes interessadas, mas em um formato que suporte múltiplas requisições como no exemplo abaixo: Requisito Rastreabilidade Stakeholder Requisito Classificação Class. projeto Prioridade Fonte Entrega onde Fulano Detalhamento pedido Desempenho, funcionalidade, Qualidade, segurança, especif. Técnica, etc Trabalho, Cronograma, Orçamento, RH, Comunicações, Riscos, Aquisições 2 Ata de reunião Z ou e- mail Y Entrega de Fase, entrega no protótipo, entrega no doc. OK X

149 Distribuir as informações (E.4) Imagem X: Exemplo de registro de requisitos Fonte: o autor. Além dos registros dos requisitos que o negociador sempre deve manter atualizado, também existem as atas de reunião. Toda reunião deve ser registrada em uma ata de reunião como no exemplo abaixo. Empresa: <nome> Projeto: <nome> Elaborado por: <nome e função> Aprovado por: <nome e função> Relação dos presentes Ata de reunião Versão: _._ Data (aprovação): / / Assuntos tratados Decisões tomadas Ações a serem empreendidas e prazos Responsável <local>, em de de Imagem X: Exemplo de uma Ata de Reunião Fonte: XAVIER, 2009, p Além destes, existe também o armazenamento das solicitações de mudanças visto no processo equipe gerenciar mudanças. Armazenando informações internas Equipe do projeto A equipe técnica constantemente criam soluções técnicas para a criação do produto, e muitas vezes elas reúnem também com o restante da equipe (exemplo: negociador, designer,...) e criam soluções de negócios para o projeto, estas soluções são vitais para a continuidade do projeto mas ao mesmo tempo trazem diversos riscos e devem ser tratadas com um mínimo de cuidado e atenção. Portanto, se a solução dada for complexa ou extensa ou se sua alteração causar impacto em outras tarefas esta solução deve ser tratada como um pedido de mudança no projeto e o processo equipe gerenciar mudanças deverá ser executado (lá possui seus métodos para registros). Soluções mais simples, que possuam menor impacto ao projeto, podem ser feitas diretamente, mas é essencial que as documente junto com o cartão kanban ou outro meio. Dúvidas quanto se a solução em questão é simples ou não pode ser retirada formando um grupo de decisão que em sua forma mais simples é constituído por pelo menos mais uma pessoa na análise. Gerenciar a comunicação do dia a dia Negociador Diariamente o negociador recebe contatos como s e precisa resolvê-los com certa urgência... Verificação Aprovar recebimento da informação Equipe do cliente As informações mais importantes exigem uma aprovação e esta significa uma concordância. Seguindo os

150 Distribuir as informações (E.4) princípios básicos da comunicação, para reduzir ruídos, o ideal que o feedback seja a resposta da seguinte pergunta: descreva, o que você entendeu?. Controlar a qualidade da informação Negociador O responsável por controlar a qualidade da informação é o negociador, exatamente por que ele é o centro da comunicação. Se ele sentir que a qualidade não está boa, então ele deve exigir uma revisão do emissor. Revisar qualidade da informação Equipe do projeto A equipe do projeto deve seguir as boas práticas da comunicação previstas neste capítulo. A revisão da qualidade da informação é essencial para que a mensagem seja compreendida por todos. Resultados Planejamento da negociação Mapa da comunicação atualizado Lista de requisitos atualizada Matriz de responsabilidade atualizada Plano de ação atualizado Kanban atualizado Um documento com uma lista de solicitações e negociações do projeto. A ideia é armazenar todas as negociações de forma organizada para que sejam lembradas, mas também organizadas de um modo a serem discutidas semanalmente. As negociações devem ser planejadas provocando um ganho mútuo já que geralmente o melhor para uma parte talvez seja o menos custoso para o fornecedor. O mapa de comunicação é o documento central deste processo, portanto, todos os seus passos tendem a gerar atualizações no mapa de comunicação. Detectando novas comunicações, ou melhores meios para se comunicar, ou surgindo novos destinatários, ou removendo alguma comunicação que já não se faz mais necessária, ou mudando as datas da comunicação. Talvez os destaques para as mudanças na execução do projeto se concentram nas negociações e modificações. O processo de distribuir informações é um dos que causam maior interação com as partes interessadas. Sendo assim, é um dos que mais coletam requisitos, já que a presença das partes interessadas geram percepções de desejos, necessidades e expectativas. Estas são registradas no documento de requisitos pois geralmente impactam na formação do produto. As responsabilidades são atualizadas com novas atividades encontradas no decorrer do projeto e também com mudanças dos atores ou simplesmente mudanças das responsabilidades. Com o decorrer do projeto e da comunicação, novas ações surgem, outras são realizadas e outras removidas da lista. Portanto, se faz necessário atualizar o plano de ação. O kanban será preenchido com as informações das tarefas como modificações e observações técnicas, fortalecendo o armazenamento das comunicações internas. O preenchimento pode ser a colagem de novos cartões, de preferência com outras cores, no próprio cartão.

151 Garantir a qualidade Garantir a qualidade (E.5) Estes são passos preventivos e tem o objetivo em assegurar se o projeto está aplicando os processos e se os processos são adequados para alcançar a qualidade. Entrada Ações preventivas e corretivas aprovadas Solicitações de mudanças aprovadas Plano de desenvolvimento do projeto Kanban Os processos são auditados ciclicamente, e as ações preventivas e corretivas da qualidade são revistas constantemente e caso não estejam aplicadas corretamente um novo planejamento é feito. Visto em Os processos são fiscalizados conferindo se as mudanças estão sendo realizadas de modo organizado e sem atrapalhar o trabalho da equipe. Inclusive se os impactos estão sendo devidamente calculados e negociados. Visto em Todo o planejamento é consultado a fim de detectar possíveis desvios do planejado e também se os processos e as pessoas estão seguindo o planejado. Visto em O kanban é utilizado pela equipe para levantar o que foi feito e o que fará nos próximos dias e inclusive detectar quais são os possíveis impedimentos para a execução destas tarefas. Como fazer? Equipe reunir-se periodicamente Equipe do projeto Reunião que acontece diariamente ou periodicamente, como 3x na semana, com o objetivo de identificar preventivamente os impedimentos do projeto e também permitir que membros do projeto se ajudem com conselhos e suporte técnico. Nesta reunião, feita em pé, de no máximo 30 minutos, são feitas três perguntas: O que fiz nos últimos X dias? O que pretendo fazer nos próximos X dias? Tem alguma coisa me impedindo? Esta reunião pode ser feita em frente ao kanban, e ele pode ser utilizado como referência inclusive para relembrar o que foi feito e o que será feito. Se ainda não souber, no momento em que estiver respondendo a estas perguntas, o membro tende a identificar certos problemas e pendências que impactarão no trabalho, ou seja, os impedimentos do trabalho são detectados. Estes impedimentos devem ser removidos para que o trabalho seja executado, e para isso ele deve pensar em possíveis soluções, e se o próprio membro não souber solucionar, ele solicita ao líder, negociador ou gerente do projeto para que removam estes impedimentos. Se as soluções resultarem em mudanças estas devem ser anotadas no kanban e o processo equipe gerenciar mudanças será executado. A equipe pode julgar necessário registrar os impedimentos e suas soluções. Realizar auditorias da qualidade Gerente de Projetos

152 Garantir a qualidade (E.5) Processo aleatório (ou periódico) onde o gerente de projetos (ou terceiros autorizados) realizam entrevistas com membros da equipe levantando entre outras: O conhecimento que o profissional possui acerca do seu papel no projeto; As informações que possui; O treinamento que possui para atender o projeto; As bases de informações que ele consulta para realizar as tarefas; Os processos que está aplicando para sua atividade; Opinião se estes processos são eficientes e eficazes; Com isso o gerente de projetos pode detectar falha e corrigi-las com melhoria da informação, treinamento, distribuição de documentos, melhoria nos processos e outras ações corretivas que garantem a qualidade do projeto. Criar ações preventivas e corretivas Gerente de projetos A partir destas reuniões preventivas de auditorias, o gerente de projetos pode sentir necessidade de criar ações preventivas e corretivas acerca o projeto ou até mesmo da empresa. Para tanto, ele pode organizar os dados levantados e realizar uma reunião com toda a equipe utilizando técnicas para a detecção e soluções de problemas. Geralmente estas técnicas resultam em uma lista de ações de melhorias e mudanças e, como nos processos anteriores, as responsabilidades devem ser distribuídas, onde para cada ação eles devem encontrar o 5W1H: o quê, por que, quem, onde, quando e como. Estas ações são salvas no plano de ação do projeto. Esta reunião também pode ser utilizada para reconhecer os acertos e fortalecer para que eles continuem. Ou, caso forem soluções simples, o próprio gerente do projeto pode criar as soluções e instruir a equipe. Verificação Revisar auditoria e ações de qualidade Gerente do projeto O gerente do projeto assegura se a auditoria foi feita com qualidade e se as ações criadas resolvem os problemas do projeto. Resultados Relatório de auditoria Plano de ações do projeto atualizado Kanban atualizado Documento formado por entrevistas e listando os acertos e erros do projeto. Este documento também lista as ações preventivas e corretivas propostas. A equipe recebe uma nova lista de ações a realizarem durante o projeto. Principalmente ações preventivas e corretivas no formato 5w1h. O kanban é atualizado com observações e descrições de mudanças e soluções de impedimentos.

153 Desenvolver a equipe do projeto Fundamentado em Desenvolver a equipe do projeto (E.6) Este processo visa aprimorar a competência (conhecimento + habilidades) da equipe, nas diversas áreas de desempenho (laboral, funcional, individual, comportamental e gerencial), efetuando a avaliação de desempenho da equipe (XAVIER, 2009, p. 129). Entrada Lista de recursos do projeto Relatórios do projeto Visto em e A lista de recursos do projeto lista todos os membros da equipe do projeto, assim como sua visão. Visto em e Os relatórios de acompanhamento (desempenho e status) e de qualidade são fontes de deficiências na equipe, permitindo o planejamento de um desenvolvimento da equipe. Como fazer? Desenvolver a equipe do projeto Gerente do projeto Segundo CHIAVENATO (2005), as técnicas para desenvolver pessoas podem ser: rotação de cargos, posições de assessoria, aprendizagem prática, atribuição de comissões, participação em cursos e seminários externos, exercícios de simulação, treinamento (outdoor) fora da empresa, estudo de casos, jogos de empresas ou de centros de desenvolvimento interno. Acrescento a estes o trabalho em par, onde quem possui conhecimento trabalha ao lado da pessoa que está aprendendo e também os grupos internos de estudos em quê profissionais internos estudam e/ou repassam novos conhecimentos essenciais ao projeto para a equipe do projeto. Avaliar o desempenho da equipe Gerente do projeto O desempenho individual pode ser avaliado formalmente pela perspectiva laboral, funcional, individual, comportamental e gerencial. Um modelo para avaliação de desempenho individual é apresentado no apêndice A (XAVIER, 2009, p. 129). O também é possível fazer uma avaliação interna de 90º onde a equipe avalia os outros membros da equipe enriquecendo o feedback. Verificação Revisar o desempenho Gerente do projeto O gerente do projeto é responsável por aplicar a avaliação de desempenho na equipe, ou por pedir que outros membros se avaliem. O resultado destas avaliações devem ser revistas e se não estiverem corretas as avaliações devem ser refeitas. Os resultados das avaliações podem servir de entrada para o desenvolvimento da equipe do projeto, a partir da análise dos gaps. Resultados

154 Desenvolver a equipe do projeto (E.6) Avaliações da equipe Plano de desenvolvimento da equipe Relatórios de avaliação da equipe, por pessoa, permitindo que os membros vejam suas deficiências a partir de feedbacks e assim permitam crescer. Podem ser utilizadas na criação de metas. Um planejamento de atividades, com plano de ação e descritivos, relativos ao desenvolvimento da equipe como cursos, grupos de estudos e etc. O ideal é que estes sejam justificados de acordo com uma necessidade da corporação Controle O Grupo de Processos de Monitoramento e Controle consiste nos processos necessários para acompanhar, revisar e regular o progresso e o desempenho do projeto, identificar todas as áreas nas quais serão necessárias mudanças no plano e iniciar as mudanças correspondentes. O principal benefício deste grupo de processos é que o desempenho do projeto é observado e mensurado de forma periódica e uniforme para identificar variações em relação ao plano de gerenciamento do mesmo. O grupo de processos de monitoramento e controle também inclui (PMI, 2008, p. 57): Controlar as mudanças e recomendar ações preventivas em antecipação a possíveis problemas; Monitorar as atividades do projeto em relação ao plano de gerenciamento e à linha de base de desempenho do mesmo e

155 155 Influenciar os fatores que poderiam impedir o controle integrado de mudanças, para que somente as mudanças aprovadas sejam implementadas. Este monitoramento contínuo fornece à equipe do projeto uma visão melhor sobre a saúde do mesmo e identifica quaisquer áreas que requeiram atenção adicional. O grupo de processos de controle organizam os processos conforme demonstrado na imagem abaixo. Esta revisão pode resultar em atualizações recomendadas e aprovadas para o plano de gerenciamento do projeto. Por exemplo, uma data de término de atividade não cumprida pode exigir ajustes no plano de pessoal atual, dependência de horas extras ou compensações entre os objetivos de orçamento e cronograma (PMI, 2008, p. 58). O grupo de processos de controle organizam os processos conforme demonstrado na imagem abaixo. Imagem X: Processos do controle. Fonte: o autor. Os tópicos abaixo descrevem detalhadamente cada um destes processos Controlar o andamento do projeto Controlar o andamento do projeto (C.1)

156 Controlar o andamento do projeto (C.1) O objetivo deste processo é coletar e disseminar as informações de desempenho, assim como alinhar a comunicação, a expectativa sobre o desempenho e relembrar ou fortalecer as informações planejadas frente à execução. Entrada Lista de recursos do projeto Como fazer? Reunião semanal de acompanhamento Líder Todos os membros da equipe participam desta reunião, com destaque para o negociador, líder, o controlador da qualidade e os técnicos que estão na execução atual do serviço. Em geral, devido ao kanban estar distribuído em entregas semanais, já existe uma percepção entre todo o time, sobre um atraso ou sobre um adianto no projeto. A reunião acontece semanalmente e inicia apresentando os cartões do kanban, ou seja, as entregas que deveriam ter sido feitas na semana. Esta reunião serve como condutora para os diversos processos vistos a seguir, listados no grupo de processos de controle. Ela é dividida em três partes, a saber: o planejado, o realizado e o a realizar. O planejado: A visão da equipe, o objetivo do projeto e a priorização das necessidades devem estar visíveis a todos e, serem relembrados quando necessário. Para estas entregas a equipe deve identificar e ler em voz alta o planejamento que deveria ter sido executado nesta semana, ou os que impactam nas atividades da semana, e o líder pode escolher destacar estes planejamentos na visão de todos em uma apresentação. Para tanto, é importante que a base de busca da relação semana/planejamento seja feita no plano de ação do projeto, e os detalhes do planejamento estão distribuídos nos seguintes documentos: Planejamento da aquisição Cronograma do projeto Plano de gerenciamento da qualidade Plano de gerenciamento dos riscos Mapa de comunicação Cronograma macro Calendário do projeto Matriz de responsabilidade Também é importante utilizar os protótipos e design das entregas da semana para que traga melhor entendimento do quê estava previsto. O realizado: Todos estando ciente do que deveria ter sido feito é a hora de apresentar o que está efetivamente feito. Para isso, a equipe responsável pela execução atual, demonstra a parte pronta do produto e assim é natural que

157 Controlar o andamento do projeto (C.1) alguns desvios e erros sejam encontrados e estes devem ser anotados pelo controlador da qualidade. É normal que nesta apresentação os responsáveis pela execução descrevam suas decisões e alterações no projeto no qual o líder ou o gerente de projetos pode solicitar comprovação de cumprimento do processo, a fim de, garantir e controlar a qualidade. Isso significa que o gerente ou líder pode perguntar se antes de fazer foi consultado o que está planejado e se as decisões foram anotadas. O negociador tem que estar atento a necessidade de comunicar os desvios e decisões do projeto as partes interessadas e também em prever possíveis atritos e impactos devido a tais mudanças. A realizar: Finalizada a apresentação, a equipe reorganiza a próxima semana do kanban, redefinindo os cartões se necessário. A ideia agora é discutir as tarefas da próxima semana do kanban, inicialmente buscando o planejado para elas (vide acima em o planejado ) incluindo as ações de qualidade e de riscos, e posteriormente entendendo as partes do produto a ser construído registrando nos cartões as alterações já previstas. Esta reorganização dos cartões e do que será feito, inclui, se necessário, prever uma nova estimativa de esforço, podendo adiantar ou atrasar o projeto. Daí soluções para aumentar a possibilidade do adiantamento ou soluções para reduzir a possibilidade do atraso podem ser criadas em conjunto. Um exemplo de solução seria: uma entrega que não foi feita na semana que se passou pode ser realizada na próxima semana, sem adiar as tarefas planejadas para a semana que vem, com uso se necessárias de horas extras ou ajuda de outros profissionais. Após a realização de algumas entregas internas, ou seja, de algumas reuniões semanais, pode ser identificada uma parte apresentável do produto. Desta forma, o negociador, com suporte da equipe, pode achar interessante apresentar uma parte pronta do produto para o cliente e dessa forma, prevenir atritos, mudanças, alinhar comunicação e expectativas, trazer transparência e melhorar o relacionamento. Registrar dados de acompanhamento Gerente do projeto Periodicamente, talvez quinzenalmente, o gerente do projeto irá resgatar os dados registrados no kanban como durações realizadas e anotações de decisões e mudanças sobre o planejado e atualizar os documentos do planejamento (com a ajuda de escolhidos dele) com destaque para o cronograma, mapa do produto, mapa do projeto e o plano de desenvolvimento do projeto. Estas alterações no registro devem ser comunicadas e assinadas com o nome, data e o quê foram modificados. Emitir relatórios de acompanhamento Gerente do projeto Em geral, devido ao kanban estar distribuído em entregas semanais, já existe uma percepção entre todo o time, sobre um atraso ou sobre um adianto no projeto. Atualizado o cronograma com horas realizadas é possível gerar diversos relatórios utilizando as variáveis horas previstas (linha de base) X horas realizadas. Seguem alguns exemplos de relatórios:

158 Controlar o andamento do projeto (C.1) Imagem X: Exemplo de relatório de trabalho dos recursos retirado do MS Project Fonte: o autor. Este relatório agrupa as horas realizadas (trabalho real) e as estimadas (trabalho linha de base) por tipo de recursos de modo que cada tipo de profissional veja o impacto que está causando no projeto. A variável trabalho é o resultado da soma do trabalho real mais o trabalho que falta ser feito, ou seja, o trabalho previsto a ser utilizado ao término do projeto, que nos casos dos profissionais um e dois tende-se ao atraso (ultrapassar a linha de base). Imagem X: Exemplo de relatório de trabalho dos recursos retirado do MS Project Fonte: o autor. Este relatório é uma análise geral e macro dos custos do projeto mostrando o custo realizado até o momento, o custo planejado (linha de base) para o projeto e o custo acumulado (custo realizado somado ao custo previsto) que representa uma previsão de custo final do projeto, que neste exemplo demonstra uma tendência ao prejuízo em 63%. Um relatório de acompanhamento que pode ser atualizado, facilmente, pela própria equipe é o gráfico de queima de tarefas ou burndown. Por fim, os relatórios devem ser distribuídos para a equipe do projeto e eventualmente para a equipe do cliente conforme processo distribuir informações. Dependendo do caso o gerente do projeto pode reunir com a equipe para informar uma situação especial como quando há crise por exemplo. Análise do valor agregado Gerente do Projeto O texto a seguir foi retirado de XAVIER (2009, p. 132) ou PMBOK PONTES (p. 28)

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

F.1 Gerenciamento da integração do projeto

F.1 Gerenciamento da integração do projeto Transcrição do Anexo F do PMBOK 4ª Edição Resumo das Áreas de Conhecimento em Gerenciamento de Projetos F.1 Gerenciamento da integração do projeto O gerenciamento da integração do projeto inclui os processos

Leia mais

GERENCIANDO PROJETOS UTILIZANDO AS PRÁTICAS DO GUIA PMBOK

GERENCIANDO PROJETOS UTILIZANDO AS PRÁTICAS DO GUIA PMBOK GERENCIANDO PROJETOS UTILIZANDO AS PRÁTICAS DO GUIA PMBOK Ana Cristina Zanetti*, Ednei Ernesto Consiglio*, Oscar Sante Ruggiero*, Paulo Sergio Tio*, Wagner Faquim*, João Carlos Boyadjian** * Aluno do curso

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

Módulo 2: Gerenciamento de Escopo, Tempo e Custos do Projeto

Módulo 2: Gerenciamento de Escopo, Tempo e Custos do Projeto ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 2: Gerenciamento de Escopo, Tempo e Custos do

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS Atualizado em 31/12/2015 GESTÃO DE PROJETOS PROJETO Para o PMBOK, projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Leia mais

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações

Módulo 3: Gerenciamento da Qualidade, dos Recursos Humanos e das Comunicações ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 3: Gerenciamento da Qualidade, dos Recursos

Leia mais

SINAL Sindicato Nacional dos Funcionários do Banco Central Conceitos básicos em gerenciamento de projetos

SINAL Sindicato Nacional dos Funcionários do Banco Central Conceitos básicos em gerenciamento de projetos Conceitos básicos em gerenciamento de projetos Projeto de regulamentação do Art. 192 da Constituição Federal Brasília (DF) Maio de 2009 i Conteúdo 1. Nivelamento de informações em Gerenciamento de Projetos...

Leia mais

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro:

Teoria e Prática. Totalmente de acordo com a 4 a Edição/2009. Rosaldo de Jesus Nocêra, PMP, PMI-SP, MCTS. do PMBOK do PMI. Acompanha o livro: Gerenciamento de Projetos Teoria e Prática Totalmente de acordo com a 4 a Edição/2009 do PMBOK do PMI Acompanha o livro: l CD com mais de 70 formulários exemplos indicados pelo PMI e outros desenvolvidos

Leia mais

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3.

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3. 02m Conteúdo Apresentação do PMBOK Brasília, 25 de Junho de 2015 Fase 01 1.PMBOK e PMI 2. Conceitos 3.Processos Fase 02 4. Áreas de Conhecimento 10m Gerenciamento de Projetos Projeto A manifestação da

Leia mais

Gerenciamento de Escopo na Gestão de Projetos

Gerenciamento de Escopo na Gestão de Projetos Gerenciamento de Escopo na Gestão de Projetos Airton Eustaquio Braga Junior aebjr@terra.com.br MBA Gestão de Projetos em Engenharia e Arquitetura Instituto de Pos-Graduação IPOG Goiania, GO, 02 de Setembro

Leia mais

MINI-CURSO Gerenciamento de Projetos para Economistas

MINI-CURSO Gerenciamento de Projetos para Economistas MINI-CURSO Gerenciamento de Projetos para Economistas ECONOMISTA - RIVAS ARGOLO 2426/D 62 9905-6112 RIVAS_ARGOLO@YAHOO.COM.BR Objetivo deste mini curso : Mostrar os benefícios do gerenciamento de projetos

Leia mais

Aula Nº 10 Planejamento da Comunicação

Aula Nº 10 Planejamento da Comunicação Aula Nº 10 Planejamento da Comunicação Objetivos da Aula: Os objetivos desta aula visam analisar as necessidades de informação para se manter os stakeholders internos e externos bem como a equipe de projetos

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Grupo de Consultores em Governança de TI do SISP 20/02/2013 1 Agenda 1. PMI e MGP/SISP 2. Conceitos Básicos - Operações e Projetos - Gerenciamento de Projetos - Escritório de

Leia mais

- Project Management Institute. Disciplina de Engenharia de Software. PMP- Project Management Professional PMBOK

- Project Management Institute. Disciplina de Engenharia de Software. PMP- Project Management Professional PMBOK Disciplina de Engenharia de Software Material elaborado por Windson Viana de Carvalho e Rute Nogueira Pinto em 19/07/2004 Material alterado por Rossana Andrade em 22/04/2009 - Project Management Institute

Leia mais

GUIA PMBOK PARA GERENCIAMENTO DE PROJETOS

GUIA PMBOK PARA GERENCIAMENTO DE PROJETOS ISSN 1984-9354 GUIA PMBOK PARA GERENCIAMENTO DE PROJETOS Emerson Augusto Priamo Moraes (UFF) Resumo Os projetos fazem parte do cotidiano de diversas organizações, públicas e privadas, dos mais diversos

Leia mais

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE

PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE. PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE PMI - PMBoK PMI PROJECT MANAGEMENT INSTITUTE PMBoK PROJECT MANAGEMENT BODY OF KNOWLEDGE 1 PMI- Project Management Institute Fundado nos Estudos Unidos em 1969; Instituto sem fins lucrativos, dedicado ao

Leia mais

GESTÃO DE PROJETOS. "Quando o mar está calmo, qualquer barco navega bem." O que é um projeto? Prof. Me. Francisco César Vendrame. W.

GESTÃO DE PROJETOS. Quando o mar está calmo, qualquer barco navega bem. O que é um projeto? Prof. Me. Francisco César Vendrame. W. GESTÃO DE PROJETOS Prof. Me. Francisco César Vendrame "Quando o mar está calmo, qualquer barco navega bem." W. Shakespeare O que é um projeto? Projeto é um empreendimento não repetitivo (único), caracterizado

Leia mais

Como concluir um projeto com sucesso?

Como concluir um projeto com sucesso? Como concluir um projeto com sucesso? Luiz Eduardo Cunha, Eng. Professor da FAAP e do IMT 1 Luiz Eduardo Cunha Graduado em Engenharia de Produção EPUSP Pós-Graduado em Gestão do Conhecimento e Inteligência

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Em conformidade com a metodologia PMI 1 Apresentações Paulo César Mei, MBA, PMP Especialista em planejamento, gestão e controle de projetos e portfólios, sempre aplicando as melhores

Leia mais

Desmembrando o PMBoK através de mapas mentais (Mindmaps)

Desmembrando o PMBoK através de mapas mentais (Mindmaps) PMI O Que é o PMBoK Guide 3º Edition? O PMBoK Guide 3º Edition (2004) é uma denominação que representa todo o somatório de conhecimento dentro da área de gerenciamento de projetos, além de fornecer uma

Leia mais

Gerenciamento de Projetos (PMI) e sua aplicação em projetos de transporte público.

Gerenciamento de Projetos (PMI) e sua aplicação em projetos de transporte público. Gerenciamento de Projetos (PMI) e sua aplicação em projetos de transporte público. Sérgio Ricardo Fortes 1 ; Ana Cristina Dalborgo 2 1 EMTU Rua Joaquim Casemiro, 290, Bairro Planalto São Bernardo do Campo-SP

Leia mais

Engenharia de Software II: Criando o cronograma do projeto. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br

Engenharia de Software II: Criando o cronograma do projeto. Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Engenharia de Software II: Criando o cronograma do projeto Prof. Msc Ricardo Britto DIE-UFPI rbritto@ufpi.edu.br Sumário Definição das atividades. Sequenciamento das atividades. Estimativa de recursos

Leia mais

Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003

Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003 Capítulo 3 Aplicando o PMBoK ao Microsoft Office Project 2003 29 3.1 GERENCIAMENTO DO ESCOPO O Gerenciamento do Escopo do Projeto engloba os processos necessários para assegurar que o projeto inclua todas

Leia mais

Cartilha. Gestão de Projetos. Superintendência de Planejamento e Gestão SUPLAN Ministério Público do Estado de Goiás

Cartilha. Gestão de Projetos. Superintendência de Planejamento e Gestão SUPLAN Ministério Público do Estado de Goiás Cartilha Gestão de Projetos SUPLAN Ministério Público do Estado de Goiás Esta cartilha tem como objetivo transmitir os conceitos básicos relacionados ao Gerenciamento de Projetos e compartilhar da metodologia

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos

Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos Visão Geral das Áreas de Conhecimento e dos Processos da Gerência de Projetos GERÊNCIA DE INTEGRAÇÃO GERÊNCIA DO ESCOPO GERÊNCIA DO TEMPO GERÊNCIA DE CUSTO GERÊNCIA DA QUALIDADE Desenvolvimento do Plano

Leia mais

Palavras-Chave: Aquisições; Planejamento de Aquisições; Controle de Aquisições; Projeto; Lead time; Processo; Meta.

Palavras-Chave: Aquisições; Planejamento de Aquisições; Controle de Aquisições; Projeto; Lead time; Processo; Meta. 1 A INFLUÊNCIA DO PLANEJAMENTO E CONTROLE DA AQUISIÇÃO NO PRAZO FINAL DO PROJETO Euza Neves Ribeiro Cunha RESUMO Um dos grandes desafios na gerência de projetos é planejar e administrar as restrições de

Leia mais

Gestão de Projetos Logísticos

Gestão de Projetos Logísticos Gestão de Projetos Logísticos Professor: Fábio Estevam Machado CONTEÚDO DA AULA ANTERIOR Teoria Gestão de Projetos Introdução História Ferramentas Áreas do Conhecimento - Exercício AULA 3 Gestão de Projetos

Leia mais

Título da apresentação Curso Gestão de Projetos I (Verdana, cor branca) Curso de Desenvolvimento de Servidores - CDS

Título da apresentação Curso Gestão de Projetos I (Verdana, cor branca) Curso de Desenvolvimento de Servidores - CDS Título da apresentação Curso Gestão de Projetos I (Verdana, cor branca) Curso de Desenvolvimento de Servidores - CDS Prof. Instrutor Elton Siqueira (a) (Arial Moura preto) CURSO DE GESTÃO DE PROJETOS I

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

O que é um projeto? Características de um projeto. O Que é o PMBoK Guide 3º Edition? Desmembrando o PMBoK através de mapas mentais (Mindmaps)

O que é um projeto? Características de um projeto. O Que é o PMBoK Guide 3º Edition? Desmembrando o PMBoK através de mapas mentais (Mindmaps) O que é um projeto? Projeto é um empreendimento não repetitivo, caracterizado por uma sequência clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido,

Leia mais

9 RECURSOS HUMANOS 10 COMUNICAÇÕES

9 RECURSOS HUMANOS 10 COMUNICAÇÕES 10 COMUNICAÇÕES O gerenciamento das comunicações do projeto é a área de conhecimento que emprega os processos necessários para garantir a geração, coleta, distribuição, armazenamento, recuperação e destinação

Leia mais

4. PMBOK - Project Management Body Of Knowledge

4. PMBOK - Project Management Body Of Knowledge 58 4. PMBOK - Project Management Body Of Knowledge No Brasil, as metodologias mais difundidas são, além do QL, o método Zopp, o Marco Lógico do Banco Interamericano de Desenvolvimento (BID) e o Mapp da

Leia mais

Pós-graduação em Gerenciamento de Projetos práticas do PMI

Pós-graduação em Gerenciamento de Projetos práticas do PMI Pós-graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

Gerenciamento da Integração com metodologia PMBOK 30 h/a

Gerenciamento da Integração com metodologia PMBOK 30 h/a da Integração com 30 h/a Facundo Barbosa, MBA, PMP, ITIL, CSP 85 9444.9544 e 85 4005.5644 facunndo@mdb.com.br Slide 1 Metodologia Explanação Discussões em grupo Exercícios práticos Apresentação e estudo

Leia mais

Objetivos da aula. Planejamento, Execução e Controle de Projetos de Software. O que é um plano de projeto? O que é um projeto?

Objetivos da aula. Planejamento, Execução e Controle de Projetos de Software. O que é um plano de projeto? O que é um projeto? Planejamento, Execução e Controle de Projetos de Software. Objetivos da aula 1) Dizer o que é gerenciamento de projetos e a sua importância; 2) Identificar os grupos de processos do gerenciamento de projetos

Leia mais

UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição

UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição Project Management Institute UM GUIA DO CONHECIMENTO EM GERENCIAMENTO DE PROJETOS (GUIA PMBOK ) Quarta Edição NOTA As

Leia mais

Módulo: Empreendedorismo Gestão de Projetos. Agenda da Teleaula. Vídeo. Logística 28/8/2012

Módulo: Empreendedorismo Gestão de Projetos. Agenda da Teleaula. Vídeo. Logística 28/8/2012 Logística Profª. Paula Emiko Kuwamoto Módulo: Empreendedorismo Gestão de Projetos Agenda da Teleaula Reforçar a importância dos projetos no cenário atual. Apresentar os principais conceitos envolvendo

Leia mais

3 Metodologia de Gerenciamento de Riscos

3 Metodologia de Gerenciamento de Riscos 3 Metodologia de Gerenciamento de Riscos Este capítulo tem como objetivo a apresentação das principais ferramentas e metodologias de gerenciamento de riscos em projetos, as etapas do projeto onde o processo

Leia mais

17/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan. Unidade 2.

17/02/2009. Curso Superior de Tecnologia: Redes de Computadores. Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan. Unidade 2. Faculdade INED Curso Superior de Tecnologia: Redes de Computadores Disciplina: Gestão de Projetos de TI Prof.: Fernando Hadad Zaidan 1 Unidade 2.2 2 ESCOPO 3 1 Gerência do Escopo Processos necessários

Leia mais

PMBOK 4ª Edição I. Introdução

PMBOK 4ª Edição I. Introdução PMBOK 4ª Edição I Introdução 1 PMBOK 4ª Edição Um Guia do Conhecimento em Gerenciamento de Projetos Seção I A estrutura do gerenciamento de projetos 2 O que é o PMBOK? ( Project Management Body of Knowledge

Leia mais

Gerenciamento do escopo

Gerenciamento do escopo Gerenciamento do escopo Gerenciamento do escopo Escopo pode ser definido como a soma dos produtos de um projeto, bem como a descrição de seus requisitos. O momento de definir o escopo é a hora em que o

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

Pós-Graduação em Gerenciamento de Projetos práticas do PMI

Pós-Graduação em Gerenciamento de Projetos práticas do PMI Pós-Graduação em Gerenciamento de Projetos práticas do PMI Planejamento do Gerenciamento das Comunicações (10) e das Partes Interessadas (13) PLANEJAMENTO 2 PLANEJAMENTO Sem 1 Sem 2 Sem 3 Sem 4 Sem 5 ABRIL

Leia mais

BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS. Por Maria Luiza Panchihak

BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS. Por Maria Luiza Panchihak BENEFÍCIOS DO GERENCIAMENTO DE PROJETOS Por Maria Luiza Panchihak Este artigo apresenta os benefícios do gerenciamento de projetos e mostra a importância desse processo, dentro de uma organização, para

Leia mais

7 Seminário em Gerenciamento de Projetos PMI-GO

7 Seminário em Gerenciamento de Projetos PMI-GO 7 Seminário em Gerenciamento de Projetos PMI-GO PROJETO: OFICINA DE GERENCIAMENTO DE PROJETOS NA ABORDAGEM PMI Vivian Borim www.vivianborim.com.br viborim@uol.com.br Agenda 22.08.2011 08h Apresentação

Leia mais

FINANÇAS AS EM PROJETOS DE TI

FINANÇAS AS EM PROJETOS DE TI FINANÇAS AS EM PROJETOS DE TI 2012 Material 2.1 Prof. Luiz Carlos Valeretto Jr. 1 Fundamentos de Risco e Retorno Se todos soubessem com antecedência qual seria o preço futuro de uma ação, o investimento

Leia mais

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Gerenciamento de Programas e Projetos nas Organizações" 4ª Edição (a ser lançada) Autor: Darci Prado Editora INDG-Tecs - 1999-2006

Leia mais

Gerenciamento de Projetos Project Management Institute. Prof. Miguel Torres miguel.torres@terra.com.br

Gerenciamento de Projetos Project Management Institute. Prof. Miguel Torres miguel.torres@terra.com.br Gerenciamento de Projetos Project Management Institute Prof. Miguel Torres miguel.torres@terra.com.br Objetivo do Curso Criar condições e proporcionar métodos para o desenvolvimento da capacidade gestora,

Leia mais

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO

A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO A IMPORTÂNCIA DO TESTE DE SOFTWARE PARA A QUALIDADE DO PROJETO Autora: LUCIANA DE BARROS ARAÚJO 1 Professor Orientador: LUIZ CLAUDIO DE F. PIMENTA 2 RESUMO O mercado atual está cada vez mais exigente com

Leia mais

PLANEJAMENTO DO ESCOPO

PLANEJAMENTO DO ESCOPO PLANEJAMENTO DO ESCOPO Dr. rer. nat. Christiane Gresse von Wangenheim, PMP Objetivo de aprendizagem desta aula Ao final desta aula, você deverá ser capaz de: Motivar a importância do planejamento de escopo.

Leia mais

Simulações em Aplicativos

Simulações em Aplicativos Simulações em Aplicativos Uso Avançado de Aplicativos Prof. Marco Pozam mpozam@gmail.com A U L A 0 4 Programação da Disciplina 20/Agosto: Conceito de Project Office. 27/Agosto: Tipos de Project Office.

Leia mais

Título da apresentação Curso Gestão de Projetos I (Verdana, cor branca) Curso de Desenvolvimento de Servidores - CDS

Título da apresentação Curso Gestão de Projetos I (Verdana, cor branca) Curso de Desenvolvimento de Servidores - CDS Título da apresentação Curso Gestão de Projetos I (Verdana, cor branca) Curso de Desenvolvimento de Servidores - CDS Prof. Instrutor Elton Siqueira (a) (Arial Moura preto) CURSO DE GESTÃO DE PROJETOS I

Leia mais

CARTILHA DE GERENCIAMENTO DE PROJETOS

CARTILHA DE GERENCIAMENTO DE PROJETOS CARTILHA DE GERENCIAMENTO DE PROJETOS 1ª edição - 2015 ÍNDICE INTRODUÇÃO...03 O QUE É UM PROJETO?...04 O QUE É UM PROGRAMA?...07 ESTUDOS E PROJETOS...08 O QUE É O GERENCIAMENTO DE PROJETOS...09 QUEM É

Leia mais

PMBOK/PMI Project Management Body of Knowledge. Gerenciamento de Projetos

PMBOK/PMI Project Management Body of Knowledge. Gerenciamento de Projetos PMBOK/PMI Project Management Body of Knowledge Gerenciamento de Projetos Organização de Projetos GERENCIAMENTO DE PORTFÓLIOS GERENCIAMENTO DE PROGRAMA GERENCIAMENTO DE PROJETOS GERENCIAMENTO DE SUBPROJETOS

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos (ref. capítulos 1 a 3 PMBOK) TC045 Gerenciamento de Projetos Sergio Scheer - scheer@ufpr.br O que é Gerenciamento de Projetos? Aplicação de conhecimentos, habilidades, ferramentas

Leia mais

PMBOK 4ª Edição III. O padrão de gerenciamento de projetos de um projeto

PMBOK 4ª Edição III. O padrão de gerenciamento de projetos de um projeto PMBOK 4ª Edição III O padrão de gerenciamento de projetos de um projeto 1 PMBOK 4ª Edição III Processos de gerenciamento de projetos de um projeto 2 Processos de gerenciamento de projetos de um projeto

Leia mais

Aula 04 - Planejamento Estratégico

Aula 04 - Planejamento Estratégico Aula 04 - Planejamento Estratégico Objetivos da Aula: Os objetivos desta aula visam permitir com que você saiba definir o escopo do projeto. Para tal, serão apresentados elementos que ajudem a elaborar

Leia mais

PMBOK - Project Management Body of Knowledge - PORTUGUÊS

PMBOK - Project Management Body of Knowledge - PORTUGUÊS PMBOK - Project Management Body of Knowledge - PORTUGUÊS Sr(as) Gerentes de Projeto, O PMBOK, compilado pela expertise do PMI Project Management Institute, é a linha mestra que nos conduz ao conhecimento

Leia mais

GERENCIAMENTO DE RISCOS EM PROJETOS: UMA COMPARAÇÃO ENTRE O PMBOK E A ISO-31000

GERENCIAMENTO DE RISCOS EM PROJETOS: UMA COMPARAÇÃO ENTRE O PMBOK E A ISO-31000 GERENCIAMENTO DE RISCOS EM PROJETOS: UMA COMPARAÇÃO ENTRE O E A -31000 Maildo Barros da Silva 1 e Fco.Rodrigo P. Cavalcanti 2 1 Universidade de Fortaleza (UNIFOR), Fortaleza-CE, Brasil phone: +55(85) 96193248,

Leia mais

Fatores Críticos de Sucesso em GP

Fatores Críticos de Sucesso em GP Fatores Críticos de Sucesso em GP Paulo Ferrucio, PMP pferrucio@hotmail.com A necessidade das organizações de maior eficiência e velocidade para atender as necessidades do mercado faz com que os projetos

Leia mais

Gerenciamento de Projetos Gerenciamento do Tempo

Gerenciamento de Projetos Gerenciamento do Tempo Gerenciamento de Projetos Gerenciamento do Tempo Metodologia Aula Teórica Exemplos e Exercícios práticos Questões de concursos anteriores Metodologia e Bibliografia Bibliografia PMBOK, 2004. Project Management

Leia mais

Gestão de Projetos Logísticos

Gestão de Projetos Logísticos Gestão de Projetos Logísticos Professor: Fábio Estevam Machado CONTEÚDO DA AULA ANTERIOR ESCOPO Teoria EAP etapas de desenvolvimento TEMPO Introdução Ferramentas Exercício: Documentação de Projetos Declaração

Leia mais

A Importância da Gestão do Escopo para a Gestão de Projetos

A Importância da Gestão do Escopo para a Gestão de Projetos Resumo A Importância da Gestão do Escopo para a Gestão de Projetos Mariana da Silva Gazen - mariana.gazen@gmail.com MBA em Gestão de Projetos em Engenharia e Arquitetura Instituto de Pós-Graduação e Graduação

Leia mais

Aula 3 Fase de Iniciação de projetos

Aula 3 Fase de Iniciação de projetos Aula 3 Fase de Iniciação de projetos Objetivos da Aula: Os objetivos desta aula são, basicamente, apresentar as atividades que constituem a fase inicial dos projetos. Alem disso, vamos discorrer sobre

Leia mais

10 áreas de conhecimento e 5 processos

10 áreas de conhecimento e 5 processos 1 10 áreas de conhecimento e 5 processos Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo Projetos são frequentemente utilizados como um meio de alcançar

Leia mais

Demais Áreas de Conhecimento do PMBOK

Demais Áreas de Conhecimento do PMBOK Residência em Arquitetura de Software Demais Áreas de Conhecimento do PMBOK Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br www.ufpa.br/srbo Gerência de Desenvolvimento 2008.2 Faculdade de Computação

Leia mais

Workshop PMBoK. Gerenciamento de Recursos Humanos

Workshop PMBoK. Gerenciamento de Recursos Humanos Workshop PMBoK Gerenciamento de Recursos Humanos Paulo H. Jayme Alves Departamento de Inovação Tecnológica - DeIT Janeiro de 2009 1 Envolvimento da equipe Os membros da equipe devem estar envolvidos: Em

Leia mais

Gerenciamento de Projetos Web. Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu.

Gerenciamento de Projetos Web. Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu. Gerenciamento de Projetos Web Professor: Guilherme Luiz Frufrek Email: frufrek@utfpr.edu.br http://paginapessoal.utfpr.edu.br/frufrek Possui Especialização em Engenharia de Software e Banco de Dados pela

Leia mais

Novidades do Guia PMBOK 5a edição

Novidades do Guia PMBOK 5a edição Novidades do Guia PMBOK 5a edição Mauro Sotille, PMP O Guia PMBOK 5 a edição (A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition), em Inglês, vai ser lançado oficialmente pelo

Leia mais

Gerenciamento de Projetos Modulo III Grupo de Processos

Gerenciamento de Projetos Modulo III Grupo de Processos Gerenciamento de Projetos Modulo III Grupo de Processos Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com PMBoK Processos de Gerenciamento de Projetos Para que um projeto seja bem-sucedido,

Leia mais

METODOLOGIA HSM Centrada nos participantes com professores com experiência executiva, materiais especialmente desenvolvidos e infraestrutura tecnológica privilegiada. O conteúdo exclusivo dos especialistas

Leia mais

Plataforma da Informação. Gerenciamento de Projetos

Plataforma da Informação. Gerenciamento de Projetos Plataforma da Informação Gerenciamento de Projetos Motivação Por que devemos fazer Projetos? - O aprendizado por projetos, faz parte de um dos três pilares de formação do MEJ; -Projetos são oportunidades

Leia mais

ASPECTOS GERAIS DE PROJETOS

ASPECTOS GERAIS DE PROJETOS ASPECTOS GERAIS DE PROJETOS O que é PROJETO Um empreendimento com começo e fim definidos, dirigido por pessoas, para cumprir objetivos estabelecidos dentro de parâmetros de custo, tempo e especificações.

Leia mais

Projetos na área de TI. Prof. Hélio Engholm Jr

Projetos na área de TI. Prof. Hélio Engholm Jr Projetos na área de TI Prof. Hélio Engholm Jr Projetos de Software Ciclo de Vida do Projeto Concepção Iniciação Encerramento Planejamento Execução e Controle Revisão Ciclo de Vida do Produto Processos

Leia mais

Gestão de Projetos Logísticos

Gestão de Projetos Logísticos Gestão de Projetos Logísticos Professor: Fábio Estevam Machado CONTEÚDO DA AULA ANTERIOR Teoria Gestão de Projetos Projetos Atualidades Tipos de Projetos Conceitos e Instituições Certificação Importância

Leia mais

Um passo inicial para aplicação do gerenciamento de projetos em pequenas empresas

Um passo inicial para aplicação do gerenciamento de projetos em pequenas empresas Instituto de Educação Tecnológica Pós-graduação Gestão de Projetos Aperfeiçoamento/GPPP1301 T132 09 de outubro de 2013 Um passo inicial para aplicação do gerenciamento de s em pequenas empresas Heinrich

Leia mais

Introdução a Gerenciamento de Projetos Prof. MSc. Fábio Assunção

Introdução a Gerenciamento de Projetos Prof. MSc. Fábio Assunção Introdução a Gerenciamento de Projetos Prof. MSc. Fábio Assunção Um projeto é um esforço temporário realizado para criar um produto ou serviço único. Ou seja, é desenvolvido a partir de uma ideia, progredindo

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

Gerenciamento de Projetos Liderança, Coaching e Gestão de Pessoas

Gerenciamento de Projetos Liderança, Coaching e Gestão de Pessoas Gerenciamento de Projetos Liderança, Coaching e Gestão de Pessoas Aula 05 Prof. Esp. Gladimir Ceroni Catarino gccatarino@senacrs.edu.br gladimir@gmail.com SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL FACULDADE

Leia mais

Capítulo 1 Introdução ao gerenciamento de projetos

Capítulo 1 Introdução ao gerenciamento de projetos Capítulo 1 Introdução ao gerenciamento de projetos 1.1 Introdução 31 1.2 O que é um projeto? 31 1.3 Ciclo de vida do projeto 33 1.4 O que é gerenciamento de projetos? 36 1.5 Relacionamento entre grupos

Leia mais

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso

Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Análise de Processos do PMBOK em uma Fábrica de Software Um Estudo de Caso Carlos Alberto Rovedder, Gustavo Zanini Kantorski Curso de Sistemas de Informação Universidade Luterana do Brasil (ULBRA) Campus

Leia mais

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos

Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combinando a norma ISO 10006 e o guia PMBOK para garantir sucesso em projetos Combining the ISO 10006 and PMBOK to ensure successful projects 1 Por Michael Stanleigh Tradução e adaptação para fins didáticos

Leia mais

Jonas de Souza H2W SYSTEMS

Jonas de Souza H2W SYSTEMS Jonas de Souza H2W SYSTEMS 1 Tecnólogo em Informática Fatec Jundiaí MBA em Gerenciamento de Projetos FGV Project Management Professional PMI Mestrando em Tecnologia UNICAMP Metodologia de apoio à aquisição

Leia mais

Capítulo 6 Gerenciamento do Tempo do projeto

Capítulo 6 Gerenciamento do Tempo do projeto Capítulo 6 Gerenciamento do Tempo do projeto 1 Introdução Vamos pensar um pouco? 2 Introdução Porquê gerenciar o tempo? Como saber se chegaremos nos objetivos no prazo estimado? Planejar e Controlar 3

Leia mais

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS

08/09/2011 GERÊNCIA DA INTEGRAÇÃO PMBOK GESTÃO DE PROJETOS GESTÃO DE PROJETOS Prof. Me. Luís Felipe Schilling "Escolha batalhas suficientemente grandes para importar, suficientemente pequenas para VENCER." Jonathan Kozol GERÊNCIA DA INTEGRAÇÃO PMBOK 1 GERÊNCIA

Leia mais

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU INSTITUTO A VEZ DO MESTRE A Aplicação do Gerenciamento de Risco nos Projetos de Implantação de ERP - Protheus. Por: Gisele Santos Ribeiro Orientador

Leia mais

Gerenciamento de Recursos Humanos e Gerenciamento de Comunicações. Sergio Scheer / DCC / UFPR TC045 Gerenciamento de Projetos

Gerenciamento de Recursos Humanos e Gerenciamento de Comunicações. Sergio Scheer / DCC / UFPR TC045 Gerenciamento de Projetos Gerenciamento de Recursos Humanos e Gerenciamento de Comunicações Sergio Scheer / DCC / UFPR TC045 Gerenciamento de Projetos Just to remember... Interação entre os processos segundo PMBOK... Cada processo

Leia mais

2. Gerenciamento de projetos

2. Gerenciamento de projetos 2. Gerenciamento de projetos Este capítulo contém conceitos e definições gerais sobre gerenciamento de projetos, assim como as principais características e funções relevantes reconhecidas como úteis em

Leia mais

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA

UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA UNIVERSIDADE CANDIDO MENDES PÓS-GRADUAÇÃO LATO SENSU AVM FACULDADE INTEGRADA GERENCIAMENTO EM TI Por: Josué Fonseca Aguiar Orientador Prof. Nelsom Magalhães Rio de Janeiro 2012 2 UNIVERSIDADE CANDIDO MENDES

Leia mais

PLANEJAMENTO - ESCOPO - TEMPO - CUSTO

PLANEJAMENTO - ESCOPO - TEMPO - CUSTO PLANEJAMENTO - ESCOPO - TEMPO - CUSTO PAULO SÉRGIO LORENA Julho/2011 1 Planejamento escopo, tempo e custo PROGRAMA DA DISCIPLINA Apresentação professor Programa da disciplina Avaliação Introdução Processos

Leia mais

Gerenciamento de Projetos de TI. Alércio Bressano, MBA

Gerenciamento de Projetos de TI. Alércio Bressano, MBA Gerenciamento de Projetos de TI Alércio Bressano, MBA Os projetos possuem em seu código genético o fracasso! Eles nasceram para dar errado! Nós é que temos a responsabilidade de conduzí-los ao sucesso!

Leia mais

PMBOK e Gerenciamento de Projetos

PMBOK e Gerenciamento de Projetos PMBOK e Gerenciamento de Projetos Gerenciamento de projetos (GP) é uma área de atuação e conhecimento que tem ganhado, nos últimos anos, cada vez mais reconhecimento e importância. Um dos principais difusores

Leia mais

Comparação da Metodologia TenStep PGP (Processo de Gerenciamento de Projetos), com o Guia PMBOK 4ª Edição - PMI

Comparação da Metodologia TenStep PGP (Processo de Gerenciamento de Projetos), com o Guia PMBOK 4ª Edição - PMI Comparação da Metodologia TenStep PGP (Processo de Gerenciamento de Projetos), com o Guia PMBOK 4ª Edição - PMI 2010 TenStep Comparação da Metodologia TenStep PGP (Processo de Gerenciamento de Projetos)

Leia mais

GERENCIAMENTO DE PROJETOS

GERENCIAMENTO DE PROJETOS GERENCIAMENTO DE PROJETOS O que é um Projeto? Regra Início e fim definidos Destinado a atingir um produto ou serviço único Escopo definido Características Sequência clara e lógica de eventos Elaboração

Leia mais

Módulo 5: Elaboração de uma EAP

Módulo 5: Elaboração de uma EAP ENAP Diretoria de Desenvolvimento Gerencial Coordenação Geral de Educação a Distância Gerência de Projetos - Teoria e Prática Conteúdo para impressão Módulo 5: Elaboração de uma EAP Brasília 2014 Atualizado

Leia mais