Gerência de Projetos em TI

GERÊNCIA DE PROJETOS EM TI Luiz Fernando Corcini Tecnologia GERÊNCIA DE PROJETOS EM TI Luiz Fernando Corcini O conceito de gestão tem evoluído muito ao longo do último século e embora não seja possível encontrar uma definição universalmente aceita existe algum consenso quanto ao fato de que a gerência de projetos deve incluir obrigato riamente um conjunto de tarefas que procurem garantir a utilização eficaz de todos os recursos disponibilizados pela organização a fim de serem atingidos os objetivos determinados Tendo em vista o contexto e as especificidades da TI neste livro tratamos da gerência de projetos nessa área sua abrangência e funcionamento nas organizações Fundação Biblioteca Nacional ISBN 9788538762973 9 788538 762973 CAPAGerência de Projetos em TIindd 1 01082017 105038 Luiz Fernando Corcini IESDE BRASIL SA Curitiba 2017 Gerência de Projetos em TI CIPBRASIL CATALOGAÇÃO NA PUBLICAÇÃO SINDICATO NACIONAL DOS EDITORES DE LIVROS RJ C815g Corcini Luiz Fernando Gerência de projetos em TI Luiz Fernando Corcini 1 ed Curitiba PR IESDE Brasil 2017 208 p il Inclui bibliografia ISBN 9788538762973 1 Tecnologia da informação Administração I Título 1743675 CDD 65805 CDU 650115 Direitos desta edição reservados à Fael É proibida a reprodução total ou parcial desta obra sem autorização expressa da Fael 2017 IESDE Brasil SA É proibida a reprodução mesmo parcial por qualquer processo sem autorização por escrito do autor e do detentor dos direitos autorais Todos os direitos reservados IESDE BRASIL SA Al Dr Carlos de Carvalho 1482 CEP 80730200 Batel Curitiba PR 0800 708 88 88 wwwiesdecombr Produção FAEL Direção Acadêmica Francisco Carlos Sardo Coordenação Editorial Raquel Andrade Lorenz Revisão IESDE Projeto Gráfico Sandro Niemicz Capa Vitor Bernardo Backes Lopes Imagem Capa ESB ProfessionalShutterstockcom ArteFinal Evelyn Caroline dos Santos Betim Sumário Carta ao Aluno 5 1 Introdução à gestão de projetos em TI 7 2 Escritório de gerenciamento de projetos 27 3 Auditoria de TI 47 4 Tópicos especiais de gestão de projetos de TI 69 5 As áreas do conhecimento da gestão de projetos 89 6 Gestão de tempo e recursos humanos 115 7 Gestão de recursos materiais e humanos 141 8 Gestão de qualidade e integração do projeto 167 Gabarito 189 Referências 199 Carta ao Aluno Projetos fazem parte do cotidiano da humanidade Desde que a espécie humana conseguiu formular o primeiro problema ou se deparou com a primeira dificuldade a ser superada teve de raciocinar aplicar recursos e desenvolver técnicas enfim precisou projetar uma solução para o problema ou dificuldade em questão De fato projetos icônicos são eternizados pela história por conta da sua importância e seu impacto na mudança de comportamento da civilização como um todo O conceito de gestão tem evoluído muito ao longo do último século e embora não seja possível encontrar uma definição universalmente aceita existe um consenso quanto ao fato de que a gerência de projetos deve incluir obrigatoriamente um conjunto de tarefas que procurem garantir a utilização eficaz de todos os recursos disponibilizados pelas organizações a fim de que estas atinjam seus objetivos específicos 6 Gerência de Projetos em TI Essa mesma visão deve ser aplicada em relação aos projetos de tecnologia da informação que exigem um controle adequado a fim de se obter os resul tados almejados pelas empresas Tendo em vista o contexto e as especificidades da TI nesta obra tratamos da gerência de projetos nessa área sua abrangência e funciona mento nas organizações No primeiro capítulo da obra apresentamos os conceitos básicos e os prérequisitos da gestão de projetos em TI suas metodologias e aplicações No capítulo seguinte abordamos o escritório de gerenciamento de proje tos ou PMO além de considerações sobre a importância das tecnologias para as empresas O terceiro capítulo trata do trabalho de auditoria de TI entendendo seus processos e modelos e o quarto capítulo versa sobre tópicos especiais de gestão de projetos da área incluindo procedimentos padrão e o mapeamento de processos No quinto capítulo apresentamos as áreas de conhecimento tratadas no modelo de melhores práticas de gerenciamento de projetos adotadas pelo Project Management Institute PMI além da gestão do escopo de projeto A gestão de tempo e recursos humanos é abordada no sexto capítulo com seus cronogramas e habilidades necessárias enquanto o capítulo seguinte trata da gestão dos materiais e equipamentos adotados nas empresas e dos riscos envolvidos nos projetos Por fim no capítulo 8 discor remos sobre a gestão de qualidade dos projetos suas ferramentas de análise e controle e a importância desses procedimentos para as organizações Mostramos assim que a gestão de projetos é formada por um verda deiro mosaico de processos que precisam estar bem alinhados para que as empresas possam desenvolver e alavancar seus negócios Desejamos uma boa leitura Introdução à gestão de projetos em TI Neste primeiro capítulo faremos um voo de reconheci mento sobre o grande tema gestão de projetos primeiramente apresentando as características e os conceitos básicos de um pro jeto bem como a descrição de seu ciclo de vida destacando quais são e como interagem as fases que o compõem Num segundo momento serão apresentados e discutidos o conceito e o histórico de gestão de projetos Por fim é apresentada uma lista de algu mas metodologias ou melhores práticas de gestão de projetos em tecnologia da informação 1 Gerência de projetos em TI 8 11 Conceitos básicos Projetos fazem parte do cotidiano da humanidade Desde que a espé cie humana conseguiu formular o primeiro problema ou se deparou com a primeira dificuldade a ser superada teve que raciocinar aplicar recursos e desenvolver técnicas enfim precisou projetar uma solução para o problema ou dificuldade em questão O ser humano é um inovador e solucionador de problemas por excelência haja vista toda a superação e evolução ocorridas desde os tempos imemoriais até os avanços tecnológicos mais recentes Como exemplo de alguns projetos podem ser citados as grandes pirâmides do Egito a torre Eiffel a invenção do avião o descobrimento das Américas a invenção do computador a construção da Catedral de Notre Dame na França a inven ção da lâmpada elétrica a exploração de petróleo entre outros De fato projetos icônicos como alguns mencionados anteriormente são eternizados pela história por conta da sua importância e impacto na mudança de comportamento da civilização como um todo mas é importante lembrar que um projeto não precisa ser algo necessariamente gigante caro e demorado e que o ato de tomar banho cortar grama aprender uma língua estrangeira viajar para a praia pintar a casa e fazer um jantar para os amigos pode ser também considerado um projeto Mas então o que é um projeto Certamente existem várias definições disponíveis para a palavra projeto e cada uma delas depende do contexto em que é aplicada O boletim do pro grama Salto para o Futuro da TV Escola 2002 p 67 apresenta algumas definições que são replicadas a seguir 2 Um projeto pode ser considerado como uma intenção pretensão ou sonho Exemplo Meu projeto é comprar uma casa 2 Um projeto pode ser uma ideia ou concepção de produto ou serviço Por exemplo Estes dois carros têm projetos muito semelhantes 2 Pode ser um esboço de uma proposta Por exemplo Todos têm direito de apresentar um projeto de lei ao Congresso 2 Projeto pode ser um desenho para orientar uma construção Por exemplo Pedi ao arquiteto que detalhasse o projeto 9 Introdução à gestão de projetos em TI 2 Pode ser uma atividade organizada com o objetivo de resolver um problema Por exemplo Precisamos iniciar o projeto de desenvol vimento de um novo motor menos poluente Na busca por definições mais detalhadas e completas temse que um pro jeto é a unidade mínima de aplicação de recursos que por intermédio de um conjunto integrado de atividades pretende transformar uma parcela da reali dade diminuindo ou eliminando um deficit ou solucionando um problema MURAKI 2014 Já para o PMBOK1 PMI 2013 p 2 projeto é um esforço temporário empreendido para criar um produto serviço ou resultado único Para Maximiano 2002 p 26 projeto é um empreendimento tem porário de atividade com o início meio e fim programados que tem por objetivo fornecer um produto singular e dentro das restrições orçamentárias para satisfazer as necessidades dos envolvidos A Norma de Diretrizes de Qualidade de Gerenciamento de Projetos afirma que projeto é um processo único constituído de um grupo de atividades coordenadas e controladas com datas de início e término empreendido para alcance de um objetivo con forme requisitos específicos incluindo limitações de tempo custo e recursos ABNT 2000 p 2 Já a ONU 1984 define projeto como um empreendi mento planejado que consiste num conjunto de atividades interrelacionadas e coordenadas com o fim de alcançar objetivos específicos dentro dos limites de um orçamento e de um período de tempo dados apud PROCHNOW SCHAFFER 2001 p 2 Agora que você já conhece a definição de projeto o próximo item irá detalhar suas características 111 Características dos projetos Com base nas definições citadas podem ser identificadas algumas carac terísticas dos projetos como destaca Vargas 2007 p 6 2 são temporários 2 geram produtos serviços ou resultados exclusivos 2 são empreendimentos não repetitivos 1 Project Management Body of Knowledge Gerência de projetos em TI 10 2 apresentam uma sequência clara e lógica dos eventos 2 possuem objetivo claro e definido 2 utilizam recursos humanos e materiais limitados É importante ressaltar que o projeto é uma atividade ou um conjunto de atividades com início e fim bem definidos isso é o projeto é temporário Caso a atividade em questão não tenha fim isto é seja uma atividade con tinuada então ela não pode ser um projeto ou não pode estar num projeto mas é classificada como parte de um produto um processo uma atividade funcional ou uma operação Operações conforme cita Recchia 2015 são em sua essência trabalhos executados repetitivamente de forma contínua e com recursos humanos e materiais dedicados exclusivamente para esse fim o que não é o caso de um projeto Entendidas as características dos projetos seguese o detalhamento do seu ciclo de vida assim como as fases que o compõem 112 Ciclo de vida do projeto Definese ciclo de vida como o conjunto de fases de um projeto con forme apresentado na Figura 1 Figura 1 Ciclo de vida do projeto Saídas do gerencia mento do projeto Nível de custos e pessoal Termo de abertura do projeto Tempo Entregas aceitas Plano de ge rencimaneto do projeto Início do projeto Organização e preparação Execução do trabalho Encerra mento do projeto Arquivamento dos documentos do projeto Fonte PMI 2013 p 39 11 Introdução à gestão de projetos em TI De modo geral as fases do projeto devem apresentar as seguintes carac terísticas MURAKI 2014 Cada fase do projeto é marcada pela entrega de um ou mais produtos deliverables como estudos de viabilidade ou protótipos funcionais No início de cada fase definese o trabalho a ser feito e o pessoal envolvido na sua execução O fim da fase é marcado por uma revisão dos produtos e do desem penho do projeto até o momento Uma fase começa quando termina a outra Quando há over lapping entre as fases chamamos essa prática de fast tracking2 Nesse caso começase a trabalhar nas próximas fases do projeto antes do fim da fase corrente entrega e revisão dos produtos Os custos são geralmente crescentes à medida que a fase avança Os riscos são geralmente decrescentes à medida que a fase avança A habilidade das partes envolvidas em alterar os produtos de cada fase é decrescente à medida que a fase avança Cada indústria apresenta diferentes fases específicas para seus projetos sendo que muitas têm suas fases detalhadamente descritas em padrões A Figura 2 apresenta além das quatro fases da Figura 1 mais uma a fase de controle Figura 2 Fases ou etapas do projeto Início Tempo Grupo de processos de iniciação Grupo de processos de execução Grupo de processos de encerramento Grupo de processos de planejamento Grupo de processos de moni toramento e controle Nível de interação entre processos Fim Fonte GOIÁS 2016 2 Termo em inglês utilizado para indicar a realização de tarefas simultâneas Para saber mais sobre fast tracking acesse httpwwwprojectbuildercombrbloghomeentrypraticavoce sabeoqueefasttracking Acesso em 10 jul 2017 Gerência de projetos em TI 12 Dessa figura identificamos com base em Viana 2016 2 Iniciação É a etapa em que se formaliza o início do projeto Deve gerar documentos que mencionam todos os recursos financei ros humanos materiais suas responsabilidades bem como o momento a atividade do cronograma em que deverão estar dis poníveis para o projeto É importante que os patrocinadores do projeto e todos os interessados participem dessa etapa 2 Planejamento Nessa fase serão planejados todos os controles todos os monitoramentos das atividades do projeto Determina também as restrições e como cada área do conhecimento deve ser gerenciada No decorrer desta obra ficará evidente que todas as áreas do conhecimento passam por essa área gerando um documento normalmente denominado de planejamento do gerenciamento de x em que x é a área do conhecimento analisada no momento 2 Execução Diz respeito à execução das atividades identificadas e ordenadas que constam no cronograma do projeto que devem ser realizadas com recursos prédefinidos no tempo e custo previstos no orçamento 2 Controle Ao se executar cada tarefa na fase de execução elas necessitarão de controle adequado para evitar ou mesmo corrigir qualquer tipo de desvio em seu encaminhamento de maneira que o resultado de cada atividade executada na fase anterior seja alcan çado dentro dos limites de aceitação do projeto 2 Finalização Nessa etapa todas as atividades do cronograma relacio nadas à criação do produto serviço ou resultado do projeto já foram realizadas É o momento de formalizar a entrega de verificar e desfa zer os contratos de locação de recursos e por fim receber dos patro cinadores e interessados o termo de aceite do projeto finalizado 13 Introdução à gestão de projetos em TI Dentre as fases especificadas é importante destacar que a fase de plane jamento é considerada como a mais importante pois ela determinará o curso de todo o projeto início meio e fim SAMBATECH 2009 A Figura 3 a seguir mostra como essas fases ou etapas se relacionam e quais são os gatilhos que as disparam Figura 3 Relação entre fases ou etapas do projeto Termo de abertura registro das partes interessadas Status Report Socilitação de mudança Ata de reunião Issues Log Plano de projeto Declaração de escopo Cronograma e orçamento Análise dos riscos Termo de aceite Lições aprendidas Iniciação Planejamento Execução Controle Encerramento Fonte ESCRITÓRIO DE PROJETOS 2016 113 A elaboração de um projeto Segundo Espíndola 2006 p 3 um projeto é um instrumento que surge como resposta a um problema Dessa forma entendese que para se ter um projeto adequado e que ao ser executado realmente resolva o problema temos que ter o problema bem identificado e delimitado pois conforme o autor conclui elaborar um projeto é antes de tudo contribuir para a solu ção de problemas transformando ideias e ações Gerência de projetos em TI 14 Figura 4 Elaboração de um projeto Definição do produto Ideia inicial Proposta básica Aprovação Definição de atividades prazos e custos Termo de aceite Modificações necessárias Fonte ESPÍNDOLA 2006 p 3 Adaptado Conforme pode ser verificado na Figura 4 o documento que detalha o projeto é o resultado de uma ideia da criação ou aperfeiçoamento para um produto ou serviço para solucionar ou mitigar um problema existente A par tir de então essa ideia deve ser decomposta em atividades e cada qual deve ter seu prazo e custo bem definidos pois de maneira geral a soma de todos os custos de todas as atividades determina o custo básico do projeto também conhecido como linha de base do custo assim como a soma de todos os prazos de todas as atividades estabelece o prazo básico do projeto também conhe cida como linha de base do tempo do projeto 15 Introdução à gestão de projetos em TI Importante destacar que para que sejam determinados os prazos e cus tos necessários para cada atividade devem ser identificados quais recursos humanos e materiais precisam ser utilizados em cada uma delas De posse de todos esses dados o gestor elabora a proposta básica do pro jeto que segue para aprovação do conselho de patrocinadores e envolvidos Como apresentado na Figura 4 caso a proposta não seja aprovada ela pode ser alterada corrigida ou adaptada com as modificações necessárias origi nando assim uma nova versão Esse processo pode ser repetido até que a proposta seja aprovada ou reprovada Uma vez aprovada os patrocinadores e demais envolvidos devem assinar o termo de aceite do projeto o qual deve ter destacado itens impor tantes tais como prazo custo e recursos humanos e materiais que devem estar disponíveis para a sua correta execução Agora que você já entendeu o que é um projeto quais são suas caracte rísticas e como funciona o seu ciclo passamos no próximo tópico a abordar o gerenciamento de projetos 12 Gerenciamento de projetos Segundo Viana 2016 gerenciamento de projetos é o ramo de trabalho que busca definir e atingir objetivos otimizando o uso de recursos como tempo dinheiro pessoas materiais energia e espaço durante o curso de um projeto Na mesma linha Souto 2011 considera que o conceito de gestão tem evoluído muito ao longo do último século e que embora não seja pos sível encontrar uma definição universalmente aceita existe algum consenso quanto ao fato de que este deve incluir obrigatoriamente um conjunto de tarefas que procurem garantir a utilização eficaz de todos os recursos disponi bilizados pela organização a fim de serem atingidos os objetivos prédetermi nados SOUTO 2011 p 23 Já o PMBOK PMI 2013 p 4 define gerência de projetos como a aplicação do conhecimento habilidades ferramentas e técnicas nas atividades do projeto para atender aos seus requisitos Gerência de projetos em TI 16 Para permitir um efetivo controle pelo gestor algumas metodologias dividem o projeto em partes distintas a serem gerenciadas e uma última parte que integra as demais pois normalmente a gestão é responsabilidade de um indivíduo chamado gerente de projetos que deve se esforçar para manter todas as partes funcionando em equilíbrio e em sintonia tendo como função máxima evitar que o projeto pare ou se torne inviável É importante destacar que o ato de manter o projeto em equilíbrio envolve invariavelmente o controle adequado de algumas demandas concor rentes tais como escopo prazo custo qualidade 121 História do gerenciamento de projetos A ideia de gerenciar as tarefas de um projeto não é nova e remonta há mais de 4000 anos desde a construção das grandes pirâmides do Egito Porém as primeiras ideias estruturadas e planificadas de um controle mais adequado que realmente conseguisse evitar problemas é bem recente Após a Revolução Industrial nos EUA a primeira grande organização a praticar tais conceitos foi a Central Pacific Railroad que começou suas atividades por volta de 1870 KIISEL 2010 com a construção da estrada de ferro transcontinental Dentre os cientistas que se destacaram na época estão Taylor3 e Gantt4 que foram os primeiros a dirigir a atenção para o ser humano e suas ativida des dentro da indústria estudando detalhadamente a ordem de operações no trabalho Gantt costumava afirmar que entre todos os problemas da adminis tração de um projeto o elemento humano é o mais importante FGV 2017 Taylor tinha como foco a eficiência5 e eficácia6 operacional na admi nistração industrial Extremista em suas teorias defendia métodos radicais e eficazes e seu controle inflexível mecanicista apesar de elevar enormemente 3 Frederick Taylor 18561915 engenheiro mecânico estadunidense escreveu o livro Adminis tração Científica em 1911 INFOESCOLA 2017 4 Henry L Gantt 18611919 assistente de Taylor na Midvale Steel foi um dos iniciadores da ciência da Administração FGV 2017 5 Eficiência está relacionada à produtividade em fazer mais com o mínimo de recursos possí veis PORTAL ADMINISTRAÇÃO 2017 6 Eficácia consiste em atingir o objetivo proposto executando algo de acordo com o que foi determinado PORTAL ADMINISTRAÇÃO 2017 17 Introdução à gestão de projetos em TI o desempenho das indústrias em que atuou gerou demissões insatisfações e estresse para seus subordinados Figura 5 Precursores da gestão de projetos Henry Laurence Gantt Frederick Taylor Fonte John R DunlapWikimedia Commons Gantt construiu diagramas com barras de tarefas e marcos que esbo çaram a sequência e a duração de todas as atividades em um processo Os diagramas de Gantt como passaram a ser conhecidos mostraram ser uma ferramenta analítica tão poderosa para gerentes que se mantiveram inaltera das por quase 100 anos O diagrama de Gantt será estudado oportunamente nos próximos capítulos desta obra Após a Segunda Grande Guerra a complexidade dos projetos deman dou novas estruturas organizacionais e levou ao surgimento dos diagramas chamados de gráficos PERT7 Program Evaluation and Review Technique e o método de caminho crítico8 Critical Path Method CPM oferecendo aos gestores maior controle sobre a execução das tarefas de um projeto O gráfico PERT e o método CPM também serão estudados oportunamente nesta obra Essas técnicas métodos e gráficos espalharamse para todos os tipos de indústria e empresas de forma que no início da década de 1960 os projetos 7 Desenvolvido em 1958 pelo Escritório de Projetos Especiais da Marinha dos EUA 8 Desenvolvido em 1957 pela Dupont Gerência de projetos em TI 18 eram encarados como organismos vivos e que para sobreviver e prosperar deveriam ter todas as suas partes funcionais trabalhando de forma integrada visando metas e cumprindo cronogramas As empresas e indústrias então se rendiam aos benefícios de organizar os trabalhos por meio de projetos e final mente depois de quase 5000 mil anos e de vários projetos icônicos a arte de gerenciar projetos era formalmente reconhecida como uma ciência O primeiro projeto reconhecido foi o Projeto Manhattan9 de criação da bomba atômica no século XX VIANA 2016 Figura 6 Outdoor na cidade de Oak Rigde no Tenessee EUA sobre o projeto Manhattan Fonte James E WestcottWikimedia Commons O Projeto Manhattan era completamente sigiloso Seu lema era O que você vê aqui o que você faz aqui o que você ouve aqui quando você sair daqui Deixe ficar aqui Os funcionários não sabiam que estavam produzindo bombas atômicas 9 Para saber mais sobre o Projeto Manhattan acesse httpwwwengquimicasantosspcom br201502bombaatomicaprojetomanhattanhtml Acesso em 20 jul 2017 19 Introdução à gestão de projetos em TI Na década de 1970 as crises de escassez de matériaprima como o petró leo levaram os cientistas e engenheiros a desenvolverem softwares específicos para planejamento e controle de projetos com grande número de atividades porém que tratassem as restrições CODAS 1987 p 34 Já na década de 1980 os microcomputadores permitiram aos gerentes de projeto acesso rápido às informações bem como a possibilidade de alte rar alguns parâmetros do projeto on the fly10 ante a mudança das situações ou imprevistos Outra característica que foi agregada ao gerenciamento de projetos foi a EAP estrutura analítica do projeto e a EAO estrutura analítica da organização cuja combinação em forma matricial permite a vinculação de atividades ou frações às unidades específicas da organização Da mesma forma que para os itens apresentados anteriormente neste capítulo a EAP e a EAO serão tratadas oportunamente mais à frente Conforme menciona Golla 2011 p 8 com o passar do tempo vários estudiosos buscaram aprimorar as teorias de Taylor e criaram metodologias que seguem uma visão mecanicista de que se pode dividir em pedaços con trolar monitorar padronizar e aprimorar o trabalho humano seguindo à risca processos formais Não cabe aqui discutir se os resultados dessas teorias tratam o homem como uma máquina ou não e se isso é bom ético sensato ou não Algumas das bases da teoria de Taylor como por exemplo a ideia que se fundamenta em resolver os problemas que resultam das relações entre funcionários assim como a ideia de que um bom funcionário não discute ordens nem instru ções mas sim executa tarefas prédeterminadas isto é faz o que lhe mandam fazer ainda é utilizada em metodologias vigentes nos dias de hoje e será apresentada a seguir 13 Metodologias de gerenciamento de projetos Agora que já abordamos projetos suas características e ciclos entende mos o que vem a ser a gerência de um projeto e conhecemos um pouco sobre 10 On the fly Termo em inglês que significa durante o voo Utilizado para indicar que as mudanças podem ser realizadas sem que o projeto seja parado Gerência de projetos em TI 20 a sua origem e história passamos a apresentar as metodologias de gerencia mento de projeto O primeiro passo é entender o que significa a palavra metodologia Sendo assim apresentamos as seguintes definições Metodologia segundo Medrano 2012 p 6 é um conjunto ou sis tema de métodos princípios e regras para regulamentar uma determinada disciplina Já o termo método segundo a mesma autora é um procedimento técnica ou maneira de se fazer alguma coisa especialmente de acordo com um plano definido Na visão de Massot 2008 a metodologia significa o estudo dos méto dos ou receitas para as etapas a serem seguidas em um determinado pro cesso e completa mencionando que são fundamentais para o desenvolvi mento dos projetos É importante destacar que apesar das metodologias por definição apresentarem uma maneira uma receita a ser seguida para a execução de uma determinada atividade dentro de uma fase de um projeto é um engano pensar que o simples fato de se utilizar uma metodologia assegura o sucesso do projeto Isso se dá porque cada empresa possui seus próprios processos sua cultura organizacional enfim suas características peculiares que devem ser levadas em conta quando se utiliza uma metodologia Dessa forma ela deve ser adaptada para cada caso Cada empresa deve desenvolver seus pró prios processos para cada projeto Não é por que funcionou na empresa X que vai funcionar na empresa Y e mais ainda não é por que funcionou no Departamento 1 da empresa X que vai funcionar no Departamento 2 da mesma empresa O modelo passado pela metodologia tem como objetivo estabelecer um conjunto de melhores práticas que devem ser utilizadas para um fim especí fico com base em estudos históricos e conhecimento da cultura organizacio nal e operacional Massot 2008 adverte que uma metodologia de trabalho mal empre gada pode causar excesso de burocracia gerando informações desnecessárias e atrapalhar o processo de desenvolvimento de um projeto em vez de ajudar 21 Introdução à gestão de projetos em TI O quadro a seguir apresenta algumas metodologias que sustentam as melhores práticas para se trabalhar com gestão de projetos em tecnologia da informação segundo Fernandes 2006 apud MASSOT 2008 p 4 Quadro 1 Modelos de melhores práticas Metodologia Escopo COBIT Control Objectives for Information and Related Technology Modelo abrangente aplicável para a audi toria e controle de processo de TI desde o planejamento da tecnologia até a moni toração e auditoria de todos os processos CMMI Capability Maturity Model Integration Desenvolvimento de produtos e projetos de sistemas de software ITIL Information Technology Infrastructure Library Infraestrutura de tecnologia da infor mação serviços de TI segurança gerenciamento da infraestrutura gestão de ativos e aplicativos etc Modelo ISO International Organization for Standardization Sistema de Qualidade ciclo de vida de software teste de software etc eSCMSP Service Provider Capability Maturity Model Outsourcing em serviços que usam TI de forma intensiva PRINCE2 Project in Controlled Environment Metodologia de gerencia mento de projetos PMBOK Project Management Body of Knowledge Base de conhecimento em gestão de projetos BSC Balance Scorecard Metodologia de planejamento de gestão estratégica Six Sigma Metodologia para melhoramento da qualidade de processos SAS 70 Statement on Auditing Standards for Services Regras de auditoria para empresas de serviços Fonte FERNANDES 2006 apud MASSOT 2008 p 4 Outra metodologia que também se destaca voltada ao mundo da gestão e planejamento de projetos de software é a metodologia Scrum Gerência de projetos em TI 22 Segundo Schwaber e Sutherland 2013 p 3 o Scrum não é um pro cesso ou uma técnica para construir produtos é um framework dentro do qual você pode empregar vários processos ou técnicas Os autores ainda destacam que essa metodologia é fundamentada na teoria de controle de processo empírico11 e que é sustentada por três pilares a transparência a inspeção e a adaptação Para esta obra adotaremos o PMBOK como modelo de melhores práti cas e metodologias de gerenciamento de projetos em TI A Figura 7 apresenta as dez áreas do conhecimento tratadas por essa metodologia Figura 7 Áreas do conhecimento Recursos Humanos Aquisições I nt eg ra çã o Pa rt es i nt er es sa da s C o m u ni ca çõ es R is c o Qualidade Tempo Custo Escopo Fonte DÁVILA 2015 11 O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões baseada no que é conhecido SCHWABER SUTHERLAND 2013 p 4 23 Introdução à gestão de projetos em TI Ampliando seus conhecimentos O texto a seguir explica cada uma das dez áreas do conheci mento nas quais se baseia o PMBOK Áreas de conhecimento do projeto SCHAEFER JÚNIOR et al 2016 p 45 Para falar sobre gestão de projetos é indispensável analisar o renomado guia PMBOK um Guia de Conhecimento em Gerenciamento de Projetos publicado pelo PMI Project Management Institute associação internacional defensora global da profissão de gerenciamento de projetos Conforme PMI 2013 a gestão de projetos envolve cinco processos distintos iniciação planejamento execução monitoramento e controle e encerramento Dentro destes cinco processos são consideradas também dez áreas do conhecimento Uma área de conhecimento representa um conjunto completo de conceitos termos e atividades que compõem um campo profissional campo de gerenciamento de projetos ou uma área de especialização Essas dez áreas de conhecimento são usadas na maior parte dos projetos na maioria das vezes dentro destas existem 47 processos estabelecidos ao geren ciamento de projetos As áreas de conhecimento são inte gração escopo tempo custos qualidade recursos humanos comunicações riscos aquisições e partes interessadas A Integração exerce papel essencial no gerenciamento de pro jetos na medida em que inicialmente cria as condições propí cias para o desenvolvimento adequado de um projeto O pro cesso de integração leva em conta os ingredientes existentes Gerência de projetos em TI 24 e ambiente onde o projeto será realizado CARVALHO RABECHINI 2011 O gerenciamento do escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário e apenas o necessário para terminar o projeto com sucesso O gerenciamento do escopo do projeto está relacionado principalmente com a definição e controle do que está e do que não está incluso no projeto PMI 2013 Segundo o PMI 2013 o gerenciamento do tempo dos pro jetos ocorre através do desenvolvimento de um cronograma À medida que as atividades do projeto são desenvolvidas a maior parte do esforço na área de conhecimento de geren ciamento do tempo do projeto ocorrerá no processo que irá controlar o cronograma tendo como principal objetivo garan tir o término pontual do trabalho do projeto O gerenciamento dos custos é uma parte extremamente importante e indispensável do gerenciamento do projeto pois é através dos custos que são estabelecidos mecanismos para a maximização dos recursos buscando atender as demandas do projeto O gerenciamento dos custos do projeto tem como meta garantir que o capital disponível seja o suficiente para a aquisição de todos os recursos para a efetivação dos trabalhos do projeto O gerenciamento da qualidade em projetos objetiva assegurar que o projeto atenda às necessidades do cliente e envolve o conjunto de atividades do projeto por todo o seu ciclo de vida Também implementa o sistema de gestão da qualidade por meio de políticas e procedimentos com propósitos de melhoria contínua de processos Este deve conscientizar toda equipe sobre a importância de buscar os objetivos da quali dade e para isso deve oferecer as condições necessárias para que a equipe possa alcançálos PMI 2013 25 Introdução à gestão de projetos em TI O gerenciamento dos recursos humanos do projeto é uma ati vidade que envolve a organização e coordenação da equipe do projeto Essa equipe é formada por pessoas com habilida des e competências profissionais necessárias ao bom desem penho e conclusão do projeto alocadas conforme a estrutura papéis e responsabilidades exigidas Atividades 1 Quais são as dez áreas do conhecimento estudadas pela metodologia apresentada pelo PMI 2 Utilizar uma metodologia adequada e abrangente garante o sucesso do projeto Por quê 3 O que é metodologia 4 Quais são as fases de um projeto Escritório de gerenciamento de projetos Neste segundo capítulo vamos tratar sobre dois assuntos muito importantes Primeiro abordaremos o escritório de geren ciamento de projetos1 ou em inglês Project Management Office PMO e aprenderemos o que é e quais são as características fun ções responsabilidades tipos e níveis existentes de PMO além de como ele pode ser adaptado às diversas estruturas organizacionais presentes nas empresas e indústrias O segundo assunto diz respeito à tecnologia da informação após uma contextualização do tema definiremos e justificaremos a necessidade de se ter uma gestão efe tiva e eficiente dos projetos em TI 1 Ou simplesmente escritório de projetos 2 Gerência de projetos em TI 28 21 O que é e como funciona um PMO Segundo o PMBOK PMBOK 2013 o escritório de gerenciamento de projetos EGP ou em inglês Project Management Office PMO é uma estrutura organizacional que padroniza os processos de governança relacio nados a projetos e facilita o compartilhamento de recursos metodologias ferramentas e técnicas Disso decorre que segundo o modelo baseado no PMI2 cada empresa ou indústria que deseja gerenciar adequadamente seus projetos deve estabele cer fisicamente um departamento composto por recursos humanos e mate riais dedicados de modo a centralizar a organização e o acompanhamento dos projetos por ela executados Ainda segundo a mesma metodologia as responsabilidades de um PMO podem variar desde fornecer funções de suporte ao gerenciamento de proje tos até ser responsável pelo gerenciamento direto de um projeto PMBOK 2013 p 11 Além disso o PMO pode estar envolvido na seleção no geren ciamento e na mobilização de recursos materiais ou humanos compartilhados ou dedicados É importante ressaltar que o PMO não é uma pessoa mas sim uma entidade ou departamento e não deve ser confundido com a figura do gestor ou gerente de projetos O PMO é uma estrutura que pode abrigar vários profissionais compartilhados ou dedicados também chamado por alguns de QG quartel general de projetos pois é o centro de informação de controle Um PMO pode conter um ou mais gerentes de projetos e uma empresa ou indústria pode possuir um ou mais PMOs De maneira geral os gerentes de projetos são responsáveis pelo aten dimento de necessidades de tarefas de equipe e necessidades individuais PMBOK 2013 p 17 É um papel estratégico pois faz a ligação entre a estratégia de execução de projetos definida pelo core business da empresa e a equipe de desenvolvimento do projeto em si O Quadro 1 apresenta as funções ou objetivos de um gerente de proje tos e de um PMO e tem o intuito de esclarecer e destacar os papéis de cada um deles 2 Project Management Institute Instituto de Gerenciamento de Projetos 29 Escritório de gerenciamento de projetos Quadro 1 Gerente de projetos x PMO Gerente de projetos Escritório de projetos PMO Concentrase nos objetivos do projeto Gerencia as principais mudanças do escopo do programa que podem ser vistas como possíveis oportunidades para melhor alcançar os objetivos de negócio Controla os recursos atribuídos ao projeto para atender da melhor forma possível os objetivos do projeto Otimiza o uso dos recursos organizacionais compartilhados entre todos os projetos Gerencia as restrições escopo cro nograma curso e qualidade etc dos projetos individuais Gerencia as metodologias padrões o risco oportunidade global e as interdependências entre os projetos no nível da empresa Fonte PROJETOS E TI 2013 O PMBOK PMBOK 2013 p 17 ainda ressalta que além das habi lidades específicas a qualquer área e das proficiências de gerenciamento geral exigidas pelo projeto o gerente de projetos necessita possuir as seguintes competências 2 Conhecimento referese ao que o gerente de projetos sabe sobre gerenciamento de projetos 2 Desempenho referese ao que o gerente de projetos é capaz de fazer ou realizar quando aplica seu conhecimento em gerencia mento de projetos 2 Pessoal referese ao comportamento do gerente de projetos na execução do projeto ou atividade relacionada A habilidade de guiar equipes liderança características de personalidade etc A criação de um departamento para o gerenciamento de projetos não é condição sine qua non3 para o sucesso de um projeto dentro de uma empresa Tudo depende da complexidade do projeto e da maturidade da empresa Entre os motivos para se implantar um PMO estão NETPROJECT 2017 3 Sine qua non expressão latina que pode ser traduzido como sem ao qual não pode ser Para esse caso está sendo usada com o sentido de indispensável essencial Gerência de projetos em TI 30 2 maior assertividade e previsibilidade na condução de projetos 2 seleção e priorização de projetos certos para o momento da empresa 2 manutenção ou até incremento das margens de lucro 2 manutenção da empresa no mercado Segundo Vaz et al 2012 o escritório de projetos é idealizado e implan tado geralmente quando a empresa sente a necessidade de aumentar a maturi dade na gestão de seus projetos para não perder competitividade e minimizar perdas durante a sua execução Porém uma vez implantado o escritório de gerenciamento de projetos apresenta algumas classificações determinantes Conforme cita Reis 2016 existem basicamente três tipos de PMO a saber 2 PMO corporativo atua em toda a corporação e é responsável por definir as regras da gestão de projetos na empresa bem como selecionar e validar projetos que ajudam a atingir os seus objetivos estratégicos e aqueles que estão de alguma forma ligados aos níveis hierárquicos mais altos 2 PMO organizacional ou departamental está diretamente ligado a uma área da organização como o setor de TI por exemplo Seu papel é mais operacional e normalmente seus profissionais traba lham diretamente com os projetos do departamento 2 PMO para fins especiais é criado com objetivos específicos e têm função muito distinta como gerenciar um programa estraté gico por exemplo Normalmente são concebidos por um determi nado período Assim como existem tipos diferentes de PMO existem também níveis diferentes de PMO com características funções e responsabilidades bem distintas dependendo basicamente do grau de maturidade da empresa e do entendimento das necessidades da gestão de projetos como é apresentado no Quadro 2 a seguir 31 Escritório de gerenciamento de projetos Quadro 2 Níveis de PMO Nível Responsabilidades e funções PMO de nível 1 Controle dos projetos monitoramento e obtenção das informações para a confecção de relatórios de status Não influencia no gerenciamento do empreendimento PMO de nível 2 Influir no andamento dos projetos por meio de definições de metodologias técnicas métricas e ferramentas a serem utilizadas além de gerir a evolução contínua do gerenciamento de projetos Auditar projetos e programas PMO de nível 3 Assegurar o alinhamento dos projetos e programas às estratégias do negócio da empresa Fonte VAZ et al 2012 É importante mencionar que as funções e responsabilidades descritas no Quadro 2 para cada nível de PMO são cumulativas conforme o nível vai aumentando isto é o PMO de nível 2 executa tudo o que o de nível 1 faz mais as suas próprias responsabilidades e funções e assim por diante Já segundo o PMBOK PMBOK 2013 existem vários tipos de estru turas de PMO nas organizações e estas variam em função do grau ou nível de controle e influência nos projetos da organização tais como 2 PMO de suporte desempenha papel consultivo nos projetos tendo como principal papel fornecer modelos indicar melho res práticas treinamentos fornecer acesso a informações e lições aprendidas em outros projetos Possui um nível de controle baixo É o correspondente ao que Vaz 2012 chama de PMO nível 1 2 PMO de controle tem a função de fornecer suporte e exige a adoção de estruturas ou metodologias de gerenciamento de proje tos por vários meios tais como modelos formulários e ferramentas específicas Possui um nível de controle médio É o correspondente ao que Vaz 2012 chama de PMO nível 2 Gerência de projetos em TI 32 2 PMO diretivo assume o controle do projeto pelo seu gerencia mento direto Possui nível de controle alto É o correspondente ao que Vaz 2012 chama de PMO nível 3 Entre os resultados e benefícios esperados de um PMO estão 2 aumentar a taxa de sucesso dos projetos 2 assegurar melhor utilização dos recursos reduzindo desperdícios e custos de longo prazo 2 adequar metodologias de projeto dinamicamente 2 promover reuniões internas e externas para acompanhamento dos projetos 2 implementar ações para manter adequadas a relação custo x prazo x escopo x qualidade É importante não confundir gerenciamento de projetos com gerencia mento de operações Conforme foi tratado no capítulo anterior projetos são por definição distintos de operações de modo que um projeto deve gerar um produto ou serviço único e deve ter início meio e fim bem definidos Já operação é definida como uma atividade continuada de manutenção de modo que o gerenciamento de operações segundo o PMI PMBOK 2013 p 12 é uma área de gerenciamento preocupada com a produção contínua de mercadorias eou serviços Seu objetivo é assegurar que as operações de negócios continuem de forma eficiente com o uso dos melhores recursos e o atendimento às exigências dos clientes Agora que já entendemos o que é um PMO como ele funciona quais são suas características e funções de acordo com sua tipologia e níveis vamos apresentar como esses escritórios de gerenciamento de projetos podem ser adequados a cada tipo de estrutura ou sistema organizacional 22 Estruturas organizacionais versus PMO Muitas instituições compreendem os benefícios de se desenvolver e implantar um PMO mas como ressalta Foresti 2015 cada empresa possui 33 Escritório de gerenciamento de projetos seu próprio sistema organizacional sua própria estrutura sua cultura e seu estilo exclusivos e todas essas características refletem em diversos fatores dentro da empresa tais como normas crenças comportamento expectati vas e valores É muito importante levar esses fatores em conta pois eles têm impacto direto em como a empresa e as pessoas dentro dela trabalham com as ideias de projeto trabalho em equipe e com a figura de um gerente de projetos em si Apesar de não ser algo a princípio tangível a cultura organizacional o estilo as normas e crenças de uma empresa estão refletidas na sua estru tura organizacional e essa sim é tangível e pode ser facilmente identificada O prévio conhecimento de como funciona a estrutura organizacional de uma empresa ou indústria facilita muito na identificação de possíveis problemas limitações ou restrições que serão encontrados na implantação de um escritó rio de projetos Tendo isto em vista os tópicos a seguir apresentam os mode los de estruturas organizacionais mais comuns bem como suas características e impactos para o PMO 221 Organização funcional clássica É uma estrutura fortemente hierárquica em que cada funcionário possui um superior bem definido os funcionários são agrupados por especialidade e os nomes dos departamentos são determinados por essas especialidades o que acaba na prática criando clãs dentro da empresa PMBOK 2013 p 22 Como exemplos podemos citar produção marketing contabilidade engenharia etc Nesse tipo de organização segundo Foresti 2015 o escopo do projeto é restrito ao limite de cada departamento separado por funções isto é cada um deles se responsabiliza apenas pela parte que cabe às suas funcionalidades independentemente dos demais departamentos Na realidade o funcionário de um departamento que participa do projeto normalmente não está a par do projeto como um todo e não tem ideia do que acontece fora do seu departa mento Isso causa um impacto muito negativo e limitante para a atuação de um gestor de projetos e ainda pior para um escritório de projetos Gerência de projetos em TI 34 A Figura 1 a seguir apresenta um esquema de uma estrutura organiza cional funcional Figura 1 Estrutura organizacional funcional As caixas cinzas representam equipes envolvidas em atividades do projeto Gerente funcional Equipe Equipe Equipe Equipe Equipe Equipe Equipe Equipe Equipe Gerente funcional Gerente funcional Executivochefe Coordenação do projeto Fonte PMBOK 2013 p 22 É importante destacar que conforme apresentado na Figura 1 não existe um gerente de projetos e sua função é dividida entre os gerentes funcio nais das diversas áreas atividade que normalmente os sobrecarrega Esse tipo de estrutura organizacional é um caso clássico em que os gerentes funcionais também responsáveis pelo projeto dão prioridade para as atividades rotinei ras disponibilização de recursos humanos e materiais do departamento em detrimento das atividades dos projetos 35 Escritório de gerenciamento de projetos 222 Organização matricial É um modelo de estrutura organizacional que fica no meio do caminho entre a estrutura funcional clássica menos adequada para projetos e a estru tura organizacional por projetos mais adequada Para esse tipo de estrutura organizacional destacamse três subtipos a saber a estrutura matricial fraca a matricial balanceada e a matricial forte A estrutura organizacional matricial fraca mantém as característi cas de uma organização baseada na estrutura funcional clássica A figura do gerente de projetos ainda não aparece tendo suas funções divididas entre funcionários e não mais gerentes de vários departamentos conforme apre sentado na Figura 2 Figura 2 Organização matricial fraca As caixas cinzas representam equipes envolvidas em atividades do projeto Gerente funcional Equipe Equipe Equipe Equipe Equipe Equipe Equipe Equipe Equipe Gerente funcional Gerente funcional Executivochefe Coordenação do projeto Fonte PMBOK 2013 p 23 Gerência de projetos em TI 36 Identificamos ainda que para o caso representado a coordenação do projeto pode ser realizada por várias pessoas todas de mesmo nível hierár quico mas que não possuem representatividade no corpo de gerentes funcio nais dificultando sobremaneira a discussão sobre captação de recursos huma nos e materiais para os projetos e sobre a prioridade de execução A Figura 3 a seguir apresenta a estrutura organizacional matricial balanceada Figura 3 Organização matricial balanceada As caixas cinzas representam equipes envolvidas em atividades do projeto Gerente funcional Equipe Equipe Equipe Equipe Equipe Equipe Gerente de projetos Equipe Equipe Gerente funcional Gerente funcional Executivochefe Coordenação do projeto Fonte PMBOK 2013 p 24 Notase claramente nessa estrutura organizacional a importância da figura do gerente de projetos mas ainda não se permite a ele desempenhar seu papel em tempo integral sendo assim um acumulador de funções Apesar de ser destacado como gerente de projetos o funcionário que acumula essa fun ção está subordinado a um gerente funcional desse modo são geradas dificul dades semelhantes às identificadas na estrutura organizacional de matriz fraca Por sua vez a Figura 4 apresenta a estrutura organizacional matricial forte 37 Escritório de gerenciamento de projetos Figura 4 Organização matricial forte As caixas cinzas representam equipes envolvidas em atividades do projeto Gerente funcional Equipe Equipe Equipe Equipe Equipe Equipe Gerente funcional Equipe Equipe Equipe Gerente funcional Gerente de projetos Gerente de projetos Gerente de projetos Chefe de gerentes de projetos Executivochefe Coordenação do projeto Fonte PMBOK 2013 p 24 Para o caso destacado na Figura 4 podemos notar que o gerente de pro jeto é reconhecido formalmente e existe uma área funcional composta apenas por gerentes de projetos Outra característica que merece ser destacada é o fato de que nesse modelo de estrutura organizacional o gerente de projeto tem representatividade hierárquica para rever especificações em caso de con flitos de interesse na alocação de recursos 223 Estrutura organizacional projetizada Essa é a estrutura organizacional ideal para qualquer gerente de projetos que tem todos os recursos humanos tecnológicos financeiros e de infraestru tura disponíveis em tempo integral para o desenvolvimento do seu projeto O esquema desse tipo de estrutura organizacional está apresentado na Figura 5 Gerência de projetos em TI 38 Figura 5 Organização por projetos As caixas cinzas representam equipes envolvidas em atividades do projeto Gerente de projetos Equipe Equipe Equipe Equipe Equipe Equipe Equipe Equipe Equipe Gerente de projetos Gerente de projetos Executivochefe Coordenação do projeto Fonte PMBOK 2013 p 25 É importante ressaltar que essa estrutura gera alto nível de ociosidade dos vários recursos disponíveis e segundo Vaz 2012 é considerada uma estrutura organizacional utópica Para evitar desperdícios afinal as empresas precisam minimizar custos e maximizar resultados na prática o que se tem são áreas projetizadas dentro de uma organização e não a organização como um todo como apresentado na Figura 5 Essa estrutura organizacional mista que surge para viabilizar o modelo utópico e muito dispendioso da estrutura organizacional por projetos é chamada de estrutura organizacional composta e é apresentada na Figura 6 39 Escritório de gerenciamento de projetos Figura 6 Organização composta As caixas cinzas representam equipes envolvidas em atividades do projeto Gerente funcional Equipe Equipe Equipe Equipe Equipe Equipe Gerente funcional Equipe Equipe Equipe Gerente funcional Gerente de projetos Gerente de projetos Gerente de projetos Chefe de gerentes de projetos Executivochefe Coordenação do projeto A Coordenação do projeto B Fonte PMBOK 2013 p 26 Nessa estrutura organizacional há uma mescla da estrutura organizacio nal de matriz forte com a estrutura organizacional de matriz fraca em que temos uma área funcional específica para a gerência de projetos e a autoridade do gestor de projetos garantida e reconhecida formalmente Temos também a representatividade hierárquica adequada para que o gestor de projetos pleiteie recursos porém cada integrante da equipe de projetos pode coordenar outro projeto ou mesmo subprojetos O PMI PMBOK 2013 p 26 ressalta que o gerente de projetos pode interagir em todos os três níveis da estrutura organizacional estratégicos de média gerência e operacionais dependendo de fatores como 2 importância estratégica do projeto 2 capacidade das partes interessadas de exercer influência sobre o projeto Gerência de projetos em TI 40 2 grau de maturidade em gerenciamento de projetos 2 sistemas de gerenciamento de projetos 2 comunicações organizacionais Por fim o Quadro 3 resume esquematicamente o que foi tratado nesta seção do capítulo identificando para cada tipo de estrutura organizacional seu impacto em características específicas dos projetos Quadro 3 Estrutura organizacional x projetos Funcional Matricial Por projeto Fraca Balanceada Forte Autoridade do gerente de projetos Pouca ou nenhuma Limitada Baixa e moderada Moderada a alta Alta a quase total Disponibilidade de recursos Pouca ou nenhuma Limitada Baixa e moderada Moderada a alta Alta a quase total Quem controla o orçamento do projeto Gerente funcional Gerente funcional Misto Gerente de projetos Gerente de projetos Função do gerente de projetos Tempo parcial Tempo parcial Tempo integral Tempo integral Tempo integral Equipe administra tiva do gerencia mento de projetos Tempo parcial Tempo parcial Tempo parcial Tempo integral Tempo integral Estrutura da organização Caracterís ticas do projeto Fonte PMBOK 2013 p 22 23 A tecnologia da informação O mundo está cada vez mais competitivo O aumento da complexidade e velocidade com que os negócios ocorrem e a crescente competitividade na arte de seduzir os clientes tanto internos quanto externos à empresa têm levado as organizações a reduzir suas estruturas outrora rígidas e imutáveis principalmente no que tange à sua flexibilidade organizacional 41 Escritório de gerenciamento de projetos Para tanto os profissionais em geral têm lançado mão das novas tecno logias dos sistemas integrados de gestão dos dispositivos móveis das redes de alta velocidade enfim dos recursos disponibilizados pela tecnologia da informação TI Isso se justifica de acordo com Souza 2009 p 4 pelo fato de que a TI vem ganhando mais força nos últimos anos e já é parte essencial de muitas empresas auxiliando na melhoria dos processos administrativos e gerenciais e facilitando a manipulação de grande quantidade de informações Mas afinal o que é tecnologia da informação Na busca por uma melhor definição foram levantadas as informações a seguir Segundo Silva 2015 tecnologia da informação ou TI é o conjunto de atividades e soluções envolvendo hardware software banco de dados e redes que atuam para facilitar o acesso a análise e o gerenciamento de informações Já para Oliveira 2016 a TI normalmente é definida como um conjunto de tecnologias soluções digitais e sistemas que permitem a captura o registro o armazenamento e a análise de dados Tenório 2007 p 36 conceitua TI como um conjunto convergente de tecnologias em microeletrônica compu tação software e hardware telecomunicaçõesradiodifusão e optoeletrônica capaz de formar um aparato integrado que suporta a veiculação e o manu seio de informações E por fim para Rezende e Abreu 2003 p 76 apud SOUZA 2009 TI é o conjunto de recursos tecnológicos e computacionais para a geração e uso de informação Como pode ser notado pelas definições supracitadas o motivo de existir da TI é o tratamento coleta armazenamento transformação e distribuição da informação Mas conforme Oliveira 2016 para que todos esses registros de dados tenham valor os profissionais de TI precisaram criar uma série de ferramentas e sistemas que interajam com arquivos e bancos de dados em busca de resultados relevantes e que permitam a tomada de decisões no dia a dia da empresa A área de TI é muito vasta assim como na medicina cada médico tem sua especialidade em TI ocorre a mesma coisa Dessa maneira o gestor de TI auxilia a empresa a não fazer investimentos desnecessários o tecnólogo em TI pode trabalhar com a administração de equipes e recursos técnicos enquanto um especialista em suporte pode ajudar usuários com problemas Gerência de projetos em TI 42 diversos OLIVEIRA 2016 Na mesma linha de pensamento Silva 2015 ressalta que o profissional de TI possui diversos segmentos de atuação tais como programação segurança da informação redes análise de sistemas infraestrutura e hardware e suporte técnico Isso posto podemos verificar que não existe outro motivo para uma empresa ou indústria gastar tempo e dinheiro na compra e instalação de um sistema integrado de gestão ou na instalação de redes de internet de alta velo cidade se não for para o cuidado adequado com o bem mais precioso de que ela pode dispor a informação Informação gera conhecimento A informação permite tomada de deci são permite analisar perspectivas verificar resultados e melhorar processos Sendo assim o uso de tecnologia para o tratamento da informação é de grande valia para o gestor de qualquer processo em qualquer segmento de mercado Como isso o domínio da gestão de projetos em tecnologia da informa ção se mostra altamente justificável e um assunto de suma importância pois as empresas para se manterem competitivas precisam investir em projetos de desenvolvimento de sistemas banco de dados segurança de dados ou mesmo infraestrutura que são investimentos consideráveis Quais são os riscos de esses projetos falharem Quais são as possibilidades de esses projetos extrapo larem o custo definido Qual a possibilidade de um desses projetos ser con cluído com qualidade duvidosa ou mesmo inferior à esperada Quem definiu cada etapa do projeto Quem é o responsável por cada fase do projeto Quais recursos devem ser disponibilizados para o projeto Como saber quando o projeto realmente acabou e atingiu o objetivo esperado e determinado Essas são algumas perguntas que a gestão adequada de projetos em TI pode ajudar a responder Ampliando seus conhecimentos Um projeto é um esforço temporário empregado na criação de um resultado que pode ser um produto ou um serviço 43 Escritório de gerenciamento de projetos Programa é um grupo de projetos relacionados que são geren ciados de forma coordenada Já um portfólio é um conjunto de projetos e programas gerenciados em grupo a fim de se atingir objetivos estratégicos Leia o texto a seguir para enten der de que modo essas práticas interagem e contribuem para o alcance das metas estratégicas organizacionais Portfólios programas e projetos PMBOK 2013 p 710 O relacionamento entre portfólios programas e projetos é tal que um portfólio se refere a uma coleção de projetos programas subportfólios e operações gerenciados como um grupo para o alcance de objetivos estratégicos Os programas são agrupados em um portfólio e englobam subprogramas projetos ou outros trabalhos que são gerenciados de forma coordenada para apoiar o portfólio Os projetos individuais que estão dentro ou fora do programa são de qualquer forma considerados parte de um portfólio Embora os projetos ou programas do portfólio possam não ser necessariamente inter dependentes ou diretamente relacionados eles estão ligados ao plano estratégico da organização por meio do seu portfólio Conforme ilustrado na Figura 7 as estratégias e prioridades organizacionais são vinculadas e possuem relações entre port fólios e programas bem como entre programas e projetos indi viduais O planejamento organizacional impacta os projetos através da priorização de projetos baseada em riscos financia mentos e outras considerações relevantes ao plano estratégico da organização O planejamento organizacional pode orientar o gerenciamento dos recursos e dar suporte aos projetos com ponentes com base nas categorias de riscos linhas específicas de negócios ou tipos gerais de projetos como infraestrutura e melhoria de processos Gerência de projetos em TI 44 Interação de gerenciamento de portfólios programas e projetos Portfólios Projetos Projetos Subprogramas Subprogramas Subportfólios Projetos Projetos Projetos Projetos Programas Programas Fonte Baseado em PMBOK 2013 p 5 Para entender o gerenciamento de portfólios o gerencia mento de programas e o gerenciamento de projetos é impor tante reconhecer as semelhanças e as diferenças entre essas disciplinas Também é útil entender como eles se relacionam com o gerenciamento organizacional de projetos GOP O gerenciamento organizacional de projetos é uma estrutura de execução da estratégia corporativa que utiliza o gerencia mento de projetos de programas e de portfólio assim como outras práticas organizacionais que possibilitam a realização da estratégia organizacional de forma consistente e previsível produzindo melhor desempenho melhores resultados e uma vantagem competitiva sustentável O gerenciamento de portfólios gerenciamento de progra mas e gerenciamento de projetos estão alinhados ou são acionados por estratégias organizacionais Por outro lado o gerenciamento de portfólios o gerenciamento de programas 45 Escritório de gerenciamento de projetos e o gerenciamento de projetos diferem na maneira em que cada um contribui para o alcance das metas estratégicas O gerenciamento de portfólios se alinha com as estratégias orga nizacionais selecionando os programas ou projetos certos priorizando o trabalho e proporcionando os recursos necessá rios enquanto que o gerenciamento de programas harmoniza os componentes dos seus projetos e programas e controla as interdependências a fim de obter os benefícios especifica dos O gerenciamento de projetos desenvolve e implementa planos para o alcance de um escopo específico que é moti vado pelos objetivos do programa ou portfólio a que está sujeito e em última instância às estratégias organizacionais O gerenciamento organizacional de projetos GOP promove a capacidade organizacional ligando os princípios e práticas do gerenciamento de projetos programas e portfólios com facilitadores organizacionais p ex práticas estruturais cultu rais tecnológicas e de recursos humanos para apoiar as metas estratégicas Uma organização mede as suas capacidades e então planeja e implementa melhorias visando o alcance siste mático das melhores práticas Atividades 1 Quais são as cinco dicas para a instalação de um PMO 2 Qual estrutura organizacional é a menos adequada para comportar a instalação de um PMO 3 Por que a estrutura organizacional por projetos é considerada utópica 4 O PMO surgiu em razão do crescimento da TI Justifique sua resposta Auditoria de TI Este terceiro capítulo trata sobre a auditoria da tecnologia da informação Iniciamos com a definição de indicador de controle destacando a sua importância no processo de auditoria Na segunda parte discorremos sobre a auditoria em si sua definição destacando o que são e para que servem as trilhas de auditoria bem como a sua relevância no processo de governança em TI e na gestão de projetos Na terceira parte destacamos os modelos de maturidade em projetos e sua contextualização na área de TI 3 Gerência de projetos em TI 48 31 Indicadores de controle No Capítulo 1 relatamos que segundo Viana 2016 gerenciamento de projetos é o ramo de trabalho que busca definir e atingir objetivos otimizando o uso de recursos como tempo dinheiro pessoas materiais energia e espaço durante o curso de um projeto Também destacamos que o ato de manter o projeto em equilíbrio envolve invariavelmente o controle adequado de algu mas demandas concorrentes tais como escopo prazo custo qualidade Nessa linha de pensamento é importante entender que para manter o projeto em equilíbrio no que se refere às áreas mencionadas precisamos de métricas para determinar se esse equilíbrio está acontecendo e ainda mais importante caso o projeto não esteja em equilíbrio é necessário saber o quão distante do equilíbrio desejado ele está Tal como um carro um navio ou um avião precisam de indicadores que determinem seus parâmetros como a velocidade do carro a altura na qual o avião se encontra num determinado momento a posição do navio a quantidade de combustível disponível e a temperatura do motor um projeto também precisa de indicadores e essas métricas eou medidas que nos permi tem definir se o projeto está em equilíbrio ou não são chamadas de indicadores de controle Os indicadores de controle são numa definição simples parâmetros que permitem avaliar a distância entre o cenário desejado pela empresa e o encontrado atualmente se as metas traçadas foram alcançadas ou se estão longe disso Já segundo Campos 2004 os indicadores de controle também conhecidos como itens de controle são características numéricas gerenciáveis pois somente o que é medido pode ser gerenciado e esse gerenciamento per mite a busca por melhores resultados Conforme o exposto precisamos ter indicadores ou itens de controle para controlar tudo o que queremos gerenciar em um projeto É muito importante entender que o que não é medido não pode ser controlado Sendo assim concluise que se quisermos controlar o tempo do projeto para veri ficar se estamos adiantados ou atrasados precisamos ter um indicador de controle que armazene esse dado Se quisermos controlar o que já foi gasto no projeto precisamos ter outro indicador para armazenar esse novo dado 49 Auditoria de TI e assim por diante Porém para além de apenas definir o que deve ser arma zenado é necessário definir também com que frequência esse indicador deve ser atualizado pois não adianta ter um indicador que mostre que o projeto vai atrasar depois que ele já atrasou ou um indicador que apresente o custo desatualizado de um projeto Não é uma boa prática entretanto trabalhar com um número muito grande de indicadores querer controlar tudo e todos pois isso leva a duas consequências desastrosas para o projeto 2 gasto excessivo com controles desnecessários para se controlar algo algum sistema ou pessoa deve verificar o estado de uma deter minada atividade e atualizar o indicador 2 indicadores que se sobrepõem frequentemente temos numa lista inadequada de indicadores alguns que têm a função de medir a mesma atividade ou situação Outro aspecto importante e que não deve ser esquecido é que os indi cadores não informam o que deve ser feito em caso de alerta vermelho eles apenas devem indicar ou fornecer um número que representa a situação atual de determinado objeto ou atividade dentro do projeto O que deve ser feito com relação a esse número e se ele representa ou não uma situação de emergência é responsabilidade da gestão de risco do projeto que veremos nos próximos capítulos desta obra Com base no apresentado temse que o uso de indicadores de controle é condição essencial para uma adequada auditoria de projetos em TI Ou seja para saber se as características intrínsecas de um projeto estão adequadas devemos realizar uma medição destas periodicamente A utilização de indicadores possibilita a correção dos rumos de uma estratégia mas esse processo exige o comprometimento do corpo empresarial da organização Não pode haver relaxamentos ou setores descompromissados com as tarefas Nesse sentido Terribili Filho 2010 enfatiza que quando se efetua uma avaliação do projeto durante seu ciclo de vida por indicadores é possível tomar decisões para mudar o rumo do projeto ou mesmo paralisálo pois os Gerência de projetos em TI 50 indicadores mostram a situação atual e as tendências Existem quatro grupos de indicadores utilizados para melhorar o controle dos projetos 2 Indicadores de impacto medem o resultado do projeto em longo prazo e sua contribuição para a organização e a sociedade Ou seja eles medem se o projeto conquistou seu propósito central 2 Indicadores de efetividade medem o resultado dos objetivos propostos em um determinado período de tempo após a produção dos resultados do projeto Por se tratar de efetividade só podem ser medidos após a produção do resultado do projeto Eles têm a função de responder a perguntas como 2 Esse projeto ajudou a empresa a aumentar seu faturamento 2 Ajudou a empresa a fidelizar mais clientes 2 Ajudou a empresa a minimizar desperdícios 2 Indicadores de desempenho monitoram os processos e subpro cessos para que as metas estipuladas sejam atingidas 2 Indicadores operacionais medem os recursos e as atividades dos projetos sinalizando qual a tendência do projeto com relação a prazo custo etc São exemplos desse tipo de indicador 2 índice de desempenho de prazo 2 índice de desempenho de custo 2 taxas de tarefas realizadas 2 desvio de esforço Segundo Barbosa 2009 umas das técnicas mais utilizadas para men suração monitoramento e controle do desempenho do projeto é o gerencia mento do valor agregado EVM Earned Value Management Sua técnica é simples ele compara o valor do trabalho efetivamente realizado com o que foi originalmente estimado no orçamento linha de base do projeto O EVM utiliza três indicadores para realizar o controle do projeto PV valor planejado AC custo real EV valor agregado em que 2 PV é o valor total orçado para ser gasto em determinada atividade 51 Auditoria de TI 2 AC é o custo desembolsado pela empresa no período da atividade relacionada pelo PV 2 EV é o montante orçado para o trabalho efetivamente realizado no período da atividade relacionada pelo PV Com base nesses índices podemos calcular os indicadores de custo CV variação de custo e CPI índice de desempenho em custo conforme apre sentado a seguir 2 CV EV AC 2 CPI EVAC Também é possível calcular dois indicadores de prazo SV variação de prazo e SPI índice de desempenho em prazo conforme apresentado nas fórmulas a seguir 2 SV EV PV 2 SPI EVPV Por fim fechamos essa primeira parte do capítulo destacando a impor tância dos indicadores conforme afirmava Edwards Deming 19001993 Não se gerencia o que não se mede não se mede o que não se define não se define o que não se conhece e não há sucesso no que não se gerencia apud SENA 2016 32 Auditoria de TI Auditoria é um exame sistemático das atividades desenvolvidas em determinada empresa ou setor que tem o objetivo de averiguar se elas as atividades estão sendo realizadas de acordo com as disposições planejadas e ou estabelecidas previamente se foram implementadas com eficácia e se estão adequadas SIGNIFICADOS 2017 Imagine uma grande rede de supermercados uma rede de fast food uma rede de farmácias ou mesmo o controle de tráfego aéreo de uma cidade um estado ou país Agora imagine o fluxo de informações que circu lam por essas empresas constantemente o número de transações o número Gerência de projetos em TI 52 de produtos comprados vendidos devolvidos estragados danificados as reclamações o número de passageiros por voo os voos atrasados as malas de cada passageiro etc Isso tudo gera uma quantidade enorme de dados cada um deles gerado a partir de uma ou mais atividades realizadas por funcionários ou por máquinas Dado o ponto evolutivo de integração mundial que atingimos como civilização é praticamente impossível suportar todo esse fluxo de dados1 e informações2 sem um potente sistema de controle interno Mas nisso reside o problema como é possível garantir que esse sistema de controle e toda a estrutura tecnológica agregada a ele seja confiável Afinal toda estrutura de TI é responsável por coletar manipular armazenar descartar e publicar dados e informações e dada a importância estratégia que conquistou não pode ser tratada como uma caixa preta Nesse sentindo para Buarque 2017 a auditoria de TI consiste em analisar vários aspectos da governança de TI3 de uma organização como por exemplo avaliar os controles de acesso lógico ao ambiente de TI os processos de TI verificar se a contratação de bens e serviços de TI é feita de acordo com as normas da organização e a legislação vigente etc Enfim consiste em afastar as dúvidas que surgem quanto à confiabilidade dos procedimentos adotados por esse sistema e com o intuito de garantir aos patrocinadores do projeto e ao próprio gestor que se está seguindo um caminho seguro e adequado Vale destacar que a auditoria de projetos de TI é parte importantís sima do processo de gestão de projetos em TI haja vista que a metodolo gia adotada pelo Project Management Institute PMI 2013 destaca como sendo uma das principais funções do PMO escritório de projetos o moni toramento da conformidade com os padrões políticas procedimentos e 1 Dados são partículas primitivas de registros estruturados São simples observações sobre um estado Os dados são facilmente armazenados e obtidos de máquinas SIQUEIRA 2005 p 24 2 Informação é um dado acrescido de contexto relevância e propósito Requer um mínimo de análise para a sua obtenção através da avaliação humana SIQUEIRA 2005 p 24 3 Governança de TI vem inserida dentro do contexto da governança corporativa e tem como propósito medir o desempenho da TI e sempre manter o alinhamento entre tecnologia e ne gócios TOMIATTI 2012 p 9 53 Auditoria de TI modelos de gerenciamento de projetos através de auditorias em projetos PMI 2013 p 11 O mesmo documento citado indica a utilização da auditoria de proces sos na fase de iniciação e planejamento de projetos PMI 2013 p 27 bem como em seu encerramento PMI 2013 p 28 Indica também a verificação e a auditoria da configuração do projeto na gerência de integração do pro jeto que garantem que a composição dos itens do projeto está adequada e foi corretamente efetuada assegurando que os requisitos funcionais definidos na documentação foram atendidos PMI 2013 p 97 De acordo com Arima 1993 exceto em algumas peculiaridades tecno lógicas que implicam aplicação de técnicas específicas a metodologia de auditoria pode ser mantida conforme apresentado na Figura 1 Figura 1 Etapas da auditoria Planejamento Levantamento Inventário Priorização e seleção Revisão e avaliação Recomendação Parecer conclusivo Sim Início Fim Ponto falho Fonte ARIMA 1993 p 23 Adaptado Essas etapas da auditoria podem ser definidas conforme detalhado a seguir ARIMA 1993 2 Planejamento do projeto de auditoria Naturalmente antes de se auditar qualquer processo de uma empresa fazse necessário Gerência de projetos em TI 54 entender e definir as características desta com relação às suas necessidades de recursos sejam eles financeiros materiais tecno lógicos ou humanos Para tanto ferramentas de monitoramento e controle são bemvindas Podem ser citados como exemplos dessas ferramentas 2 cronograma de execução 2 quadro de recursos tecnológicos 2 quadro de recursos humanos 2 quadro de recursos materiais 2 Levantamento dos itens a serem auditados Essa etapa do pro cesso deve fornecer um entendimento pleno e global das caracte rísticas do processo a ser auditado numa visão macro Nesse sen tido podem ser utilizadas entrevistas e análise de documentação de maneira a identificar e expor as informações relevantes para o entendimento do processo e suas relações com os demais processos da empresa 2 Identificação e inventário dos pontos de controle4 A caracterís tica do processo em questão permite identificar os diversos pontos de controle que merecem ser validados 2 Priorização e seleção dos pontos de controle Nessa etapa é rea lizado o sequenciamento dos pontos de controle identificados na etapa anterior a serem auditados Essa priorização ou sequencia mento é realizada normalmente em função do grau de risco5 repre sentado pelo objeto de um determinado ponto de controle 2 Revisão e avaliação dos pontos de controle Essa etapa consiste em executar testes de validação dos pontos de controle segundo 4 Ponto de controle qualquer documento de entrada ou saída arquivos rotinas que a equipe achar importante destacar e monitorar ARIMA 1993 5 Grau de risco a análise de risco baseiase na verificação dos prejuízos que poderá acarretar ao processo ou à empresa em curto médio e longo prazos O método de análise de risco para a auditoria consiste em saber com antecedência quais as prováveis ameaças que aquele ponto de controle representa em um sistema de informação ou processo da empresa ARIMA 1993 55 Auditoria de TI as especificações de controle interno determinado pela auditoria e com base na governança de TI com o intuito de evidenciar falhas ou fraquezas de controle interno 2 Acompanhamento e conclusão da auditoria Após a execução dos testes de validação os resultados deverão ser objeto de relató rios de auditoria e deverão conter o diagnóstico ou a situação atual em que se encontram os pontos de controle apontando as fraque zas e falhas caso existam Um fator importante a considerar ainda segundo Arima 1993 é que caso um ponto de controle apresente alguma falha ou fraqueza de controle interno ele deverá ser transformado em ponto de auditoria Isso significa que o referido ponto sofrerá nova revisão e avaliação após o prazo estabelecido para a tomada de medidas corretivas Do que foi exposto até o momento podemos considerar que o obje tivo máximo da auditoria é determinar se os processos realizados no projeto possuem a capacidade de atender às necessidades da empresa fiscalizando se as leis estabelecidas para os serviços de TI estão sendo cumpridas CNASI 2012 Além disso uma boa auditoria deverá 1 elaborar e monitorar metas 2 detectar pontos críticos que possam arriscar o cumprimento dessas metas 3 reduzir os riscos de erros e fraudes 4 certificar informações confiáveis e oportunas No entanto conforme Cnasi 2012 deve ser tomado muito cuidado com o estresse causado pelos quatro itens relatados como funções de uma boa auditoria Devese concentrar esforços na solução de problemas e na busca por melhorias Dois itens devem ser muito bem controlados 2 o clima de caça às bruxas atrás de culpados por falhas ocorridas 2 o desconforto ou até boicote por parte dos funcionários em iden tificar ou mesmo relatar os itens que precisam ser monitorados por conta da desconfiança em relação aos verdadeiros objetivos da auditoria Gerência de projetos em TI 56 É importante destacar ainda que a auditoria de TI que pode ser interna ou externa não está restrita à auditoria de sistemas de informação mas abrange todo o universo tecnológico de uma empresa departamento ou setor Desse modo são destacados a seguir os estilos de auditoria 2 Auditoria de infraestrutura de TI A infraestrutura de TI de uma empresa compõese de hardware software tecnologia de gestão de dados tecnologia de rede e serviços de tecnologia A auditoria de infraestrutura de TI atua no sentido de reduzir riscos envolvidos na disponibilidade da infraestrutura e inclui eficácia eficiência e confiabilidade de TI 2 Auditoria de desenvolvimento de sistemas Auditoria de sis temas é uma atividade voltada à avaliação dos procedimentos de controle e segurança vinculados ao processamento das informações e tem como funções documentar avaliar e monitorar sistemas de controle legais gerenciais de aplicação e operacionais Essa auditoria tem como objetivo entre outros certificar que 2 as informações são corretas e oportunas 2 existe um processamento adequado das operações 2 as informações estão protegidas contra fraudes 2 existe proteção contra situações de emergências 2 Auditoria de segurança física A segurança física tem como objetivo proteger equipamentos e informações contra usuários não autorizados prevenindo o acesso a esses recursos e deve estar baseada no monitoramento do perímetro dos recursos computa cionais em questão podendo ser explícita como uma sala cofre ou implícita como áreas de acesso restrito Segundo Pinheiro 2009 p 4 a segurança física pode ser abordada sob duas formas segu rança de acesso em que são tratadas medidas de proteção contra o acesso físico não autorizado e segurança ambiental em que são tratadas medidas de prevenção por causas naturais 57 Auditoria de TI 2 Auditoria de integridade de dados Também chamada de audi toria lógica compreende um conjunto de medidas e procedimentos adotados pela empresa ou intrínsecos aos sistemas utilizados com o intuito de proteger dados programas e sistemas contra tentativas de acesso não autorizado realizadas por usuários ou outros progra mas Com base em Pinheiro 2009 p 15 a seguir estão relaciona dos alguns recursos que precisam ser protegidos 2 aplicativos programas fonte e objeto 2 arquivos de dados 2 utilitários e sistemas operacionais 2 arquivos de senha 2 arquivo de log O mesmo autor ainda destaca alguns pontos de auditoria conve nientes em se tratando de segurança lógica 2 apenas usuários autorizados devem ter acesso aos recursos computacionais 2 os usuários devem ter acesso apenas aos recursos realmente necessários para a execução de suas tarefas 2 os usuários não podem executar transações incompatíveis com suas funções 2 Auditoria de planejamento e gestão Fornece uma análise pro funda da empresa e o mais importante determina a aptidão da equipe incluindo uma avaliação individual de cada executivo e sua adequação à estratégia da organização GRATERON 1999 321 Trilhas de auditoria Em se tratando de identificar pontos de controle e auditar as atividades em projetos fazse necessário além de conhecer o resultado da auditoria dado mediante relatório dos indicadores de controle nos pontos de controle Gerência de projetos em TI 58 selecionados saber quais ações foram executadas e quem as executou para gerar aquele resultado Tornase então necessário um mecanismo de gra vação e recuperação das ações ou eventos que foram realizados e dos atores dessas ações ou eventos dentro do projeto auditado Seguindo esse raciocínio seria bom se pudéssemos registrar tudo cada ação do usuário sobre o sistema ou processo mas é fácil de perceber que isso causaria na prática problemas de espaço de armazenamento e lentidão de processamento Porém por outro lado registrando o mínimo necessário correse o risco de não identificar justamente aquela ação que permitiria des vendar o problema identificado Nesse sentido as trilhas de auditoria devem ser bem planejadas para cobrirem o que é relevante dentro do processo Outros dois fatores importantes e que devem ser considerados quanto ao uso de trilhas de auditoria são 2 Por quanto tempo se deve armazenar os dados coletados pela trilha de auditoria 2 O que fazer se o espaço de armazenamento dos dados coletados pela trilha de auditoria der sinais de que está se esgotando Ter um rastro de tudo aquilo que foi feito ou consultado no sistema ou mesmo dentro do projeto é um recurso precioso para qualquer gestor con forme afirmam Garcia et al 2005 p 9 destacando que as trilhas de audito ria possibilitam prover um mecanismo de aperfeiçoamento e proteção contra as principais ameaças e vulnerabilidades na correção de falhas diagnosticadas e nas tentativas de acesso e violação de sistemas e processos Agora que já entendemos o que são indicadores de controle parte 1 e auditoria de TI e as trilhas de auditoria parte 2 passamos para a terceira parte deste capítulo que aborda o modelo de maturidade de gerenciamento de projetos de TI 59 Auditoria de TI 33 Maturidade de gerenciamento O conceito de maturidade foi inicialmente estabelecido pelo psicólogo Argyris 1968 e segundo ele para que os indivíduos se transformem em pessoas maduras são necessárias mudanças graduais ao longo do tempo con forme eles vão adquirindo competências COSTA RAMOS 2013 p 236 A maturidade precisa ser conquistada pelo planejamento e por ações tomadas para a aquisição dessas competências Para Kerzner 2017 o conceito de maturidade é definido como o desenvolvimento de sistemas e processos que são por natureza repetitivos e garantem uma alta probabilidade de que cada um deles seja um sucesso Isso posto temos que a maturidade em gerenciamento de projetos está ligada diretamente à habilidade de uma organização em gerenciar seus projetos 331 Modelos de maturidade de gestão de projetos Modelo de maturidade de gestão de projetos é um referencial para ava liar a capacidade de processos na realização de objetivos localizar oportunida des de melhorias de produtividade e qualidade e de redução de custos e pla nejar e monitorar as ações de melhoria contínua dos processos empresariais COSTA RAMOS 2013 p 237 Destacamos a seguir os principais modelos de maturidade 3311 Capability Maturity Model CMM É um modelo desenvolvido para aplicação específica em softwares em um contexto de qualidade total no âmbito de uma organização Desenvolvido pela Universidade Carnegie Mellon e pelo Instituto de Engenharia de Software foi apoiado pelo departamento de defesa do EUA e divulgado a partir de 1991 Nesse modelo a empresa é encaixada em níveis de maturidade que variam de 1 inicial a 5 otimização conforme apresenta a figura a seguir Gerência de projetos em TI 60 Figura 2 Níveis de maturidade do CMM 1 Inicial Processos imprevisivel e sem controle 4 Gerenciado Processo previsível e controlado 2 Repetível Processo disciplinado 5 Otimização Processo aperfeiçoado continuamente 3 Definido Processo consistente e padronizado Fonte SOFTWARE ENGINEERING INSTITUTE 1997 apud COSTA RAMOS 2013 p 238 Adaptado Em que 2 O nível 1 inicial representa organizações cujos projetos normal mente ultrapassam os prazos e custos originais 2 O nível 2 repetição representa organizações cujo planejamento de projetos está baseado na experiência passada e por isso são mais realistas que as empresas categorizadas como nível 1 2 O nível 3 definição representa organizações que possuem pro cessos bem definidos melhorando sobremaneira o desempenho dos projetos 2 O nível 4 gerência representa organizações que controlam pro cessos e produtos de forma quantitativa 2 O nível 5 otimização representa organizações que gerenciam plenamente seus projetos e atuam em forma de melhoria contínua 61 Auditoria de TI 3312 Project Management Maturity Model PMMM Desenvolvido por Kerzner em 2001 com base no Project Management Body of Knowledge PMBOK o modelo sugere que para uma empresa alcançar a excelência em gerenciamento de projetos é necessário galgar cinco níveis A avaliação da maturidade é realizada por meio de um questionário con tendo 183 questões de múltipla escolha COSTA RAMOS 2013 p 239 Já segundo Oliveira et al 2004 p 29 esse é um modelo que pro põe nitidamente avaliar a maturidade de toda uma organização voltado para a alta administração sendo a base de um planejamento estratégico para o gerenciamento de projetos Assim como o CMM esse modelo divide a maturidade organizacional em cinco níveis conforme apresentado na Figura 3 Figura 3 Níveis de maturidade do PMMM Nível 1 Linguagem comum Conhecimento básico Processos definidos Controle de processo Melhoria no processo Nível 2 Processos comuns Nível 3 Metodologia singular Nível 4 Benchmarking Nível 5 Melhoria contínua Fonte KERZNER 2001 apud OLIVEIRA et al 2004 p 32 Adaptado Em que 2 No nível 1 linguagem comum a organização reconhece a importância do gerenciamento de projetos Gerência de projetos em TI 62 2 No nível 2 processos comuns a organização reconhece que processos comuns precisam ser definidos e desenvolvidos de forma que o sucesso de um projeto possa ser replicado nos demais 2 No nível 3 metodologia singular a organização reconhece os efeitos sinérgicos gerados pela combinação de todas as metodolo gias corporativas em uma única 2 No nível 4 benchmarking a organização reconhece que a melhoria nos processos é necessária para manter uma vanta gem competitiva 2 No nível 5 melhoria contínua a organização inclui o arquivo de lições aprendidas a transferência de conhecimento e o planeja mento estratégico em gestão de projetos 3313 Organizational Project Management Maturity Model OPM3 O OPM3 foi elaborado a fim de fornecer um caminho para que as organizações entendessem o gerenciamento de projetos organizacional e con seguissem medir sua maturidade confrontando com um grande conjunto de boas práticas de gerenciamento de projetos OLIVEIRA et al 2004 p 60 Lançado no início de 2004 pelo Project Management Institute PMI foi desenvolvido com base na pesquisa de outros tantos modelos preexisten tes de avaliação de maturidade organizacional e com o apoio anônimo de aproximadamente 800 voluntários de mais de 35 países inclusive do Brasil COSTA RAMOS 2013 p 239 Segundo Oliveira et al 2004 p 59 o modelo OPM3 pode ser divi dido fisicamente em três partes a saber 2 texto contendo conceitos e fundamentos do modelo 2 ferramenta de autoavaliação da maturidade da organização 2 diretório contendo 586 melhores práticas e suas capacitações necessárias 63 Auditoria de TI O diferencial do OPM3 em relação aos demais modelos é que segundo Costa e Ramos 2013 p 240 ele não utiliza uma classificação em níveis e sim em valores percentuais É constituído por três elementos Conhecimento Knowledge aborda o gerenciamento e a maturidade de projetos organizacionais Avaliação Assessment apresenta métodos processos e procedimen tos pelos quais uma organização pode autoavaliar sua maturidade Aperfeiçoamento Improvement processo para se mover da atual maturidade para um nível maior Tratase de um banco de dados com a descrição de aproximadamente 600 melhores práticas COSTA RAMOS 2013 p 240 3314 Modelo de maturidade em gerenciamento de projetos MMGP Esse modelo foi lançado em 2002 por Darci Prado e permite avaliar o grau de maturidade de um setor ou departamento de uma organização PRADO 2008 Segundo Costa e Ramos 2013 p 240 os critérios adotados para a concepção do MMGP foram 2 adoção de níveis do modelo CMM para desenvolvimento de softwares que aborda níveis de maturidade de 1 a 5 2 simplicidade questionário de 40 questões e universalidade isto é ser aplicável a qualquer tipo de organização 2 relacionar a maturidade da organização com a capacidade de execu tar projetos com sucesso Esse modelo tal como o modelo CMM e o PMMM possui cinco níveis de maturidade a saber 2 nível 1 inicial 2 nível 2 conhecimento Gerência de projetos em TI 64 2 nível 3 padronização 2 nível 4 gerenciado 2 nível 5 otimizado Porém segundo Oliveira et al 2004 p 46 para cada um dos níveis pode haver cinco dimensões de maturidade conhecimento de gerenciamento uso prático de metodologias relacionamentos humanos estrutura organiza cional e alinhamento com os negócios da organização O quadro a seguir apresenta o relacionamento entre os níveis e as dimen sões do modelo MMGP Quadro 1 Características dos níveis do MMGP por dimensão Dimensão da maturidade Nível de Maturidade 1 Inicial 2 Conhecido 3 Padronizado 4 Gerenciado 5 Otimizado Conhecimentos Dispersos Básicos Básicos Avançados Avançados Metodologia Não há Tentativas Isoladas Implantada e Padronizada Melhorada Estabilizada Relacionamentos humanos Boa vontade Algum avanço Algum avanço Algum avanço Maduros Estrutura organizacional Não há Não há Implantada Melhorada Estabilizada Alinhamento com estratégias Não há Não há Não há Alinhado Alinhado Fonte PRADO 2008 apud OLIVEIRA et al 2004 p 47 Adaptado Dessa forma finalizamos a visão geral sobre a maturidade de gerencia mento de projetos bem como o presente capítulo que também abordou os indicadores de controle e auditoria em TI Naturalmente que a proposta deste texto não é esgotar o conhecimento sobre o tema nem o abordar de todas as perspectivas Dito isso para o aprofundamento sobre o assunto pas samos a seguir à leitura complementar deste capítulo 65 Auditoria de TI Ampliando seus conhecimentos O texto a seguir explica o que é a governança de TI e sua importância na implementação de estratégias das organizações O que é a governança da TI CORREIA 2010 p 1012 Governança das TI Tecnologias de Informação é o termo utilizado para descrever a forma como os responsáveis pela gestão de uma organização consideram as TI na supervisão monitorização controle e direção da mesma O modo como as TI são aplicadas na organização tem um elevado impacto na capacidade de esta alcançar a sua visão missão e objetivos estratégicos IT Governance Institute ITGI 2003 Adicionalmente a governança das TI é da responsabilidade da direção e da gestão executiva sendo assim uma parte inte grante da governança corporativa que consiste na liderança criação de estruturas organizacionais e processos que assegu ram que as TI sustentam e estendem as estratégias e objetivos da organização ITGI 2003 Por outro lado Symons 2005 descreve a governança das TI como o processo pelo qual as decisões sobre investimentos em TI são tomadas nomeadamente Quem toma as decisões Quem é responsável Por que é que a decisão é tomada Como é que a decisão é tomada e Como são medidos e monitorizados os resultados das decisões Mas para se tomarem decisões é necessário dispor de infor mações controles processos e procedimentos e de todo um framework de responsabilidades para estimular comporta mentos desejáveis na utilização das TI Weill e Ross 2004 Gerência de projetos em TI 66 Assim quanto mais rápida e precisa for a informação mais eficaz é a gestão e a orientação da área de TI e do negócio para o sucesso Todos estes mecanismos estimulam a transparência das institui ções para com os seus investidores evidenciando a aplicação real dos investimentos e comparando o retorno esperado com o alcançado até determinado momento Por que governar as TI Segundo Nolan e McFarlan 2005 após o susto provo cado pelo Bug do ano 2000 as administrações sentiram a enorme dependência das suas empresas relativamente aos SI TI bem como o risco associado Os mesmos autores identificam entre outras duas grandes motivações que levam as administrações a governar os seus SI TI Necessidade de conformidade com SarbanesOxley nos EUA e Basileia II na Europa e Reconhecimento de que os projetos de TI podem facilmente sair do controle e dessa forma afetar profundamente o desempenho da organização Por outro lado o ITGI 2003 descreve que a administração e os gestores das organizações têm necessidade de avaliar a sua capacidade em Obter vantagens competitivas através da capacidade instalada dos seus SITI para fazer face a novos modelos de negócio e a alterações das práticas do negó cio Equilibrar os custos progressivos das TI e o respectivo aumento do valor da informação de modo a obter um retorno apropriado dos investimentos em TI Gerir o risco de ter atividade num mundo digital interrelacionado e de estar dependente de entidades de controlo externo à empresa Gerir o impacto das TI na continuidade do negócio devido à crescente dependência na informação e nas TI em todos os aspectos da empresa Manter a capacidade das TI em construir e manter o conhecimento essencial para sustentar e proporcionar o crescimento do negócio e Evitar falhas nas TI 67 Auditoria de TI cujo impacto é cada vez mais visível quer no valor quer na reputação da empresa Através da implementação de metodologias de governança das TI a organização potencia a melhor compreensão dos aspectos e da importância estratégica das TI permitindolhe suportar melhor as suas operações e implementar estratégias adequadas para promover as suas atividades no futuro Atividades 1 O que são indicadores de controle 2 Qual a importância dos indicadores de controle na auditoria de TI 3 Diferencie ponto de controle de ponto de auditoria 4 Defina a governança de TI Tópicos especiais de gestão de projetos de TI Neste capítulo veremos como um gestor faz para enten der o problema em que está envolvido ou em que vai se envolver Aprenderemos que um processo pode ser detalhado em fluxos que descrevem cada passo ou atividade que precisa ser realizada Veremos também que alguns processos precisam ser regidos por regras ou padrões para assegurar a sua correta execução e que toda essa busca pela otimização de processos depende da correta identifi cação de indicadores de controle 4 Gerência de projetos em TI 70 41 Entendendo o problema Como já foi descrito em capítulos anteriores ferramentas como os indi cadores de controle e a auditoria de projetos auxiliam em muito na manuten ção do controle de projetos de TI Porém os indicadores de controle precisam ser relevantes isso é capazes de apresentar dados coerentes e significativos caso contrário o que teremos é um agrupamento de dados que não nos pos sibilitam tomar qualquer decisão Para que o gestor possa identificar quais são os indicadores de con trole relevantes e apropriados dentro de um projeto ele precisa conhecer o ambiente as circunstâncias as atividades características operacionais e as nuances negociais envolvidas no projeto em questão ou seja o gestor do projeto precisa entender o problema para o qual será designado Para tanto destacamos o mapeamento de processos como técnica valiosa para atingir esse objetivo Antes de tratarmos exatamente sobre como mapear processos preci samos abordar os conceitos de processo e sua importância para a empresa Nesse sentido Hammer e Champy 1994 definem processo como um grupo de atividades realizadas numa sequência lógica com o objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de clientes CAMPOS LIMA 2012 Por sua vez Heldman 2005 p 16 destaca que cada processo tem suas próprias características e produz resultados que servem de insumos para o próximo grupo ou no caso do processo de encerramento servem de apro vação final para o projeto em si Vale lembrar que um projeto é dividido conforme vimos no Capítulo 1 desta obra nas seguintes fases 2 iniciação 2 planejamento 2 execução 2 monitoramento e controle 2 encerramento 71 Tópicos especiais de gestão de projetos de TI Cada uma dessas fases ou processos precisa ser detalhada em atividades e cada atividade precisa ser medida e controlada por meio de indicadores pois um processo sem indicadores bem definidos e controlados é indício de uma gestão de projetos inadequada visto que aquilo que não é medido não pode ser controlado Nessa linha de pensamento Dinsmore 2009 p 136 destaca que Medir um processo é importante para determinar se está atendendo aos requisitos do cliente entender como está sendo executado e con cluir ressaltando que um indicador de resultados mensura o processo em termos de satisfação dos requisitos do cliente e é utilizado para mostrar se o trabalho do processo está estabilizado e se existem pro blemas que podem impactar os resultados finais Para Villela 2000 p 41 um processo dispõe de inputs outputs tempo espaço ordenação objetivos e valores que interligados logicamente irão resultar em uma estrutura para fornecer produtos ou serviços ao cliente Como base nas ideias supracitadas adotaremos a seguinte definição para processo uma sequência de atividades que devem estar organizadas numa determinada ordem para se atingir um objetivo gerar determinado produto ou serviço previamente estabelecido Para além das atividades puramente operacionais e repetitivas entender como funcionam os processos da empresa pode ajudar na implementação de estratégias nas operações do negócio pois por refletirem como a empresa funciona os processos ajudam a colocar em prática a visão e os valores orga nizacionais CAMPOS LIMA 2012 Apresentamos a seguir uma representação esquemática do contexto de um processo Figura 1 Processo Entrada Processo Saída Fonte CAMPOS LIMA 2012 p 1 Adaptado Gerência de projetos em TI 72 A Figura 1 serve como base para o entendimento do funcionamento básico de um processo e podemos extrapolálo para entender os processos de gerenciamento de projetos com suas cinco fases características anteriormente citadas conforme o esquema apresentado a seguir Figura 2 Figura 2 Fases ou processos de gerenciamento de projetos Iniciação Planejamento Execução Fechamento Monitoramento e controle Insumos Resultados Iniciação Monitoramento e controle Monitoramento e controle Monitoramento e controle Planejamento Planejamento Planejamento Execução Execução Fechamento Monitoramento e controle Execução Fonte HELDMAN 2005 p 19 Identificamos que cada fase processo do gerenciamento de projetos tem como insumo a saída resultado de um ou mais processos do mesmo projeto Outro ponto a ressaltar neste momento é que tão importante quanto saber quais são as entradas insumos e saídas resultados de um determinado pro cesso é conhecer cada atividade que deve ser executada dentro dele O mapeamento do processo isso é a identificação da sequência das atividades que o compõem normalmente é apresentado graficamente por um fluxo ou sequência de atividades A sequência de atividades dentro de um processo também pode ser detalhada textualmente por meio da descrição em texto livre ou ordenado numericamente de cada ação que o compõe 73 Tópicos especiais de gestão de projetos de TI Utilizaremos o diagrama de atividades como ferramenta para a apresen tação gráfica do processo mapeado e o use case descritivo como ferramenta para a descrição textual das atividades de cada processo seguindo padrão definido pela linguagem de modelagem unificada UML O detalhamento das atividades de um determinado processo depende da equipe do projeto mas vale lembrar que a boa prática de gestão de proje tos sugere que ele seja detalhado o máximo possível para sua execução ficar clara a todos os níveis de envolvidos desde os que dominam o assunto até os que estão tendo contato com o processo e suas atividades ou tarefas pela primeira vez As tarefas segundo Villela 2000 p 46 podem ser classificadas em rotineiras e não rotineiras compostas por procedimentos que por sua vez são responsáveis pela forma específica de executar o trabalho A execução de trabalho pode ser classificada como formal indica como quando e onde realizar o trabalho ou informal em que um conjunto de práticas não escritas são incorporadas à realização do trabalho Como exemplo de procedimentos que podem estar relacionados em um processo qualquer de um projeto apresentamos as figuras a seguir que demonstram o fluxo de atividades de um serviço de delivery de pizzas Figura 3 Fluxo de atividades relativas ao processo de atendimento ao cliente Cliente faz o pedido Motoqueiro entrega o valor recebido ao funcionário Funcionário registra pedido Cliente paga a pizza Pizzaiolo monta a pizza Motoqueiro entrega a pizza Fonte Elaborada pelo autor Gerência de projetos em TI 74 Figura 4 Exemplo do fluxo de atividades de um processo Escolher pizza Encomendar pizza Perguntar pela pizza Fome de pizza Pedido de pizza Pedido Recebido Pedido atendido Pizza Dinheiro Recibo 60 minutos Fome satisfeita Pagar pela pizza Comer pizza Acalmar cliente Entregar pizza Processo de teleentega de pizza Entregador Pizzaiolo Atendente Clientre Preparar pizza Receber pagamento Pizza entregue Onde está minha pizza Fonte SGANDERLA 2012 Note que as figuras anteriores são exemplos de fluxo de atividades ou tarefas decorrentes do detalhamento do processo de atendimento ao cliente porém possuem graus de detalhamento diferentes Qual delas é a mais ade quada Como detalhar um processo Como saber qual nível de detalhamento está correto Esses são os tópicos que abordaremos na segunda parte deste capítulo que trata do mapeamento de processos 75 Tópicos especiais de gestão de projetos de TI 42 Mapeamento de processos Mapear processos é a capacidade de chegar ao entendimento e cla reza da definição de cada atividade com seus respectivos custos e prazos bem definidos O mapeamento de processo ou modelagem de processos é uma ferra menta gerencial e de comunicação que tem a finalidade de ajudar a melhorar os processos existentes ou de implantar uma nova estrutura voltada para pro cessos CAMPOS LIMA 2012 p 5 Villela 2000 p 51 destaca alguns benefícios citando que a análise do mapa de processos permite a redução de custos no desenvolvimento de pro dutos e serviços a redução nas faltas de integração entre sistemas e a melhora do desempenho da organização Já Mello 2008 p 27 ressalta que o mapea mento permite documentar todos os elementos que compõem um processo e corrigir qualquer um desses elementos que esteja com problemas sendo uma ferramenta que auxilia na detecção de atividades não agregadoras de valor O autor conclui enfatizando que podem ser utilizadas várias técnicas para o mapeamento de processos com diferentes enfoques Com base no exposto podese considerar que para cada processo mapeado há um conjunto de atividades relacionadas para as quais pode se aplicar uma série de perguntas na busca de indicadores de controle tais como É necessário que a atividade seja complexa e confusa como se apresenta atualmente É possível dividila em partes mais simples e mais facilmente monitoráveis É necessário esse grande número de departamentos envolvidos para esse processo As pessoas envolvidas no processo estão ou foram adequa damente treinadas O processo atinge o objetivo para o qual foi proposto Os custos das atividades envolvidas no processo estão adequados à situação da empresa Sob a análise do gestor de TI o mapeamento do processo iniciase com o entendimento da definição de seu objetivo e segue para a decomposição desse processo gerando uma lista de atividades ou tarefas que ao serem exe cutadas na ordem correta permitem que o objetivo do processo seja atingido Gerência de projetos em TI 76 Boas práticas sugerem que para iniciar a descrição dessa lista de ativida des o gestor ou responsável deve identificar os atores envolvidos no processo em questão e realizar várias entrevistas semiestruturadas que permitam aos que executam as atividades e tarefas envolvidas no processo falar aberta e cla ramente a respeito destas destacando suas dificuldades suas ideias e soluções enfim sua rotina diária A primeira pergunta a ser feita é Como você faz seu trabalho quando nenhum problema erro ou limitação acontece Essa questão gera um deta lhamento da rotina do trabalho do entrevistado que fornece ao gestor uma noção do caminho principal desse processo O caminho ou fluxo principal pode ser definido como a sequência de atividades ou tarefas que são realizadas dentro de um processo em que tudo acontece sem nenhum erro dificuldade problema ou limitação como pode ser observado na Figura 5 Figura 5 Caminho principal Atividade 1 Atividade 2 Atividade n Fonte Elaborada pelo autor Naturalmente que dada a complexidade de alguns processos é difí cil garantir que todas as suas atividades sejam executadas sem a ocorrência de problemas limitações ou erros decorrentes de mau entendimento falha mecânica etc Sendo assim é normal que a resposta a essa primeira pergunta forneça elementos abrindo o leque de oportunidade para perguntas mais específicas em que o gestor entrevistador poderá identificar quais são os caminhos alternativos e as exceções do processo em questão O caminho ou fluxo alternativo é definido como a sequência de ativida des que deve ser realizada caso alguma atividade dentro do caminho principal não possa ser realizada em decorrência de um erro problema ou limitação conforme apresentado no esquema da Figura 6 77 Tópicos especiais de gestão de projetos de TI Figura 6 Caminho alternativo Atividade 1 Atividade 2 Atividade n Atividade 2 Alternativa Fonte Elaborada pelo autor Podemos identificar que as atividades da primeira linha são as atividades do caminho principal e a atividade da segunda linha é a atividade alternativa para a atividade principal que só deverá ser executada quando algo de errado acontecer na execução da atividade 2 Ainda observando a mesma figura podemos identificar que se algo de errado acontecer com a atividade 1 ou com a atividade n por exemplo não existe atividade alternativa a ser realizada portanto podemos considerar que se algo de errado acontecer durante a execução de uma dessas atividades o processo vai parar e o sistema vai travar Chamamos esse fato de exceção É a famosa tela azul característica do sistema operacional Windows Exceção é o estado que o sistema ou processo se encontra quando algo de errado acontece em uma atividade do caminho principal e não existe ati vidade alternativa definida Como consequência desse estado de exceção o sistema ou processo trava Figura 7 Exceções Atividade 1 Atividade 2 Atividade n Exceção Atividade 2 Alternativa Fonte Elaborada pelo autor Gerência de projetos em TI 78 Vale lembrar que a atividade alternativa não é imune a erros portanto analisando a figura se algo de errado acontecer com a execução da atividade 2 a atividade alternativa 2 entra em ação Mas e se algo de errado acontecer na execução dessa atividade alternativa A reposta naturalmente é caso não haja outra atividade planejada isso é a alternativa da alternativa o sistema ou processo vai travar Mas então quantas alternativas de alternativas devem ser planejadas para que um determinado processo não pare Depende da importância negocial e estratégica desse processo Por isso o gestor de projetos deve ter todos os pro cessos mapeados e todas as atividades inerentes a eles devem ser catalogadas sendo relativas ao caminho principal e aos caminhos alternativos Figura 8 Caminho principal caminho alternativo e exceção Atividade 1 Atividade 2 Atividade n Exceção Atividade 2 Alternativa Atividade 1 Alternativa Atividade 1 Alternativa da alternativa Fonte Elaborada pelo autor A Figura 8 mostra que se algo de errado acontecer na execução da ativi dade 1 a atividade alternativa 1 entra em ação e se algo de errado acontecer com a atividade alternativa 1 a atividade 1 alternativa da alternativa deve entrar em ação Note que uma nova exceção irá acontecer caso a atividade 1 alternativa da alternativa não for realizada corretamente Sendo assim num caso utó pico podemos pensar numa atividade que possua uma sequência infinita de atividades alternativas de modo que se alguma delas não puder ser executada corretamente por conta de um erro defeito problema ou limitação uma alternativa automaticamente é acionada e nesse cenário essa atividade em questão nunca daria em uma exceção isto é nunca iria travar 79 Tópicos especiais de gestão de projetos de TI É claro que essa é uma solução utópica pois não é viável nem factí vel Portanto o gestor ao identificar uma atividade crítica isso é de grande importância estratégica para a empresa deve providenciar um bom profissio nal e um bom equipamento tentando garantir em grande medida que essa atividade seja executada sempre pelo seu caminho principal Vale lembrar que as atividades de importância mais estratégica e que precisam por consequência ter um ou mais fluxos alternativos devem ser colocadas como indicadores e pontos de controle na auditoria dos processos Como auxílio ao gestor na entrevista dos atores envolvidos no pro cesso Pentland et al 1999 p 6 apud VILLELA 2000 p 66 sugerem uma sequência de questões a serem realizadas conforme demonstra o Quadro 1 Quadro 1 Sequência de questões Questões relativas aos processos Você pode falar a respeito das atividades em que está envolvido Você pode citar as atividades que compõem este processo Quais prazos você tem que cumprir Quais documentos você encontra em seu trabalho diário Questões relativas às atividades Quais são os responsáveis por desenhar essas atividades que você executa Quais são os objetivos dessas atividades O que você tenta realizar Quais são os objetivos dos departamentos ou indivíduos envolvidos nessa atividade Quais relatórios você precisa preencher ou ter disponível para essa atividade Quais relatórios essa atividade produz Quais produtos ou serviços essa atividade produz Quais fatores são de importância crítica para a execução correta dessa atividade Fonte PENTLAND et al 1999 p 6 apud VILLELA 2000 p 66 Ao final das entrevistas com os atores de determinado processo o ges tor terá em mãos o rascunho para duas listas a primeira com a descrição do caminho principal do processo e a segunda com a descrição dos caminhos alternativos e exceções Gerência de projetos em TI 80 Como exemplo vamos retomar o processo de atendimento ao cliente em uma pizzaria Ao entrevistar os atores envolvidos no processo funcio nários do balcão da pizzaria o pizzaiolo e o entregador o gestor pode ter identificado as seguintes situações Lista de atividades do caminho principal do processo de atendi mento do pedido 1 O cliente entra no site da pizzaria 2 O cliente escolhe a pizza sabores tamanho etc que deseja 3 O cliente confirma o pedido 4 O sistema envia o pedido para a pizzaria 5 O atendente recebe o pedido 6 O atendente atualiza o status do pedido 7 O atendente passa o pedido para o pizzaiolo 8 O pizzaiolo prepara a pizza 9 O pizzaiolo entrega a pizza para o entregador 10 O entregador segue para o endereço do cliente 11 O entregador entrega a pizza solicitada ao cliente 12 O cliente paga pela pizza 13 O entregador recebe o pagamento 14 O pedido foi atendido Note que os 14 passos do caminho principal representam atividades que devem ser realizadas para que o pedido uma vez realizado seja aten dido É importante destacar que não precisam ser exatamente 14 passos Dependendo de quem está mapeando o processo esse detalhamento terá mais passos ou menos mas independentemente do número de passos deter minados eles devem descrever as atividades relevantes para o processo e devem ser executados na ordem determinada sob pena de causarem o insu cesso na sua realização 81 Tópicos especiais de gestão de projetos de TI Repare também que ao detalhar cada atividade da 1ª até a 14ª é impor tante destacar com clareza o sujeito que realiza a ação e qual ação ele realiza caso contrário as atividades ficam passíveis de interpretação e podem gerar dúvidas no momento de análise dos dados gerados pelos indicadores de controle Após esse detalhamento do caminho principal o gestor passa a questio nar os atores envolvidos no processo sobre o que eles fazem quando algo dá errado nas atividades relacionadas Didaticamente utilizamos a seguinte expressão E se para cada ati vidade relacionada no caminho principal do processo em questão para tentar identificar o que pode dar errado Utilizando o mesmo exemplo do atendimento ao pedido do cliente temos a seguinte lista de perguntas 1 E se o site estiver fora do ar 2 E se o cliente não entender como fazer o pedido no site 3 E se o sabor que o cliente deseja não estiver disponível no site N E se o entregador confundir o endereço do cliente N E se a forma de pagamento escolhida pelo cliente não estiver disponível Repare que as perguntas são apenas um exemplo das dezenas que podem ser realizadas para entender o que pode dar errado e qual é o procedimento adotado quando isso acontece Cada uma dessas perguntas possui uma ou mais resposta Caso a res posta dada seja um procedimento que permita que o objetivo do processo seja atingido a resposta à pergunta é denominada de alternativa e fará parte do caminho alternativo do processo Caso contrário se a resposta à pergunta não permitir que o objetivo do processo seja atingido ela será considerada uma exceção e fará parte da lista de exceções do processo Para o exemplo dado de atendimento do pedido do cliente podemos considerar como exemplo de caminho alternativo o seguinte caso Gerência de projetos em TI 82 Questão 2 E se o cliente não entender como fazer o pedido no site Resposta O site possui para cada página e para cada função da pági na um ícone de ajuda que pode ser acessado toda vez que o cliente não souber como proceder Esse ícone de ajuda abre um menu popup que esclarece passo a passo como o cliente deve proceder para fazer o que deseja Perceba que a resposta à questão 2 exemplificada anteriormente per mite que o cliente realize seu pedido atingindo o objetivo do processo Por isso a resposta à questão 2 é uma alternativa Já para o exemplo de exceção podemos utilizar a seguinte questão Questão 1 E se o site estiver fora do ar Resposta Se o site estiver fora do ar o cliente não poderá realizar seu pedido e como consequência não poderá ser atendido pela pizzaria via site Note que a resposta à questão 1 exemplificada anteriormente não per mite que o cliente realize seu pedido e sendo assim ele não pode ser atendido pela pizzaria Por isso a resposta à questão 1 é uma exceção Agora que você já entendeu como se mapeia um processo passamos para a terceira parte deste capítulo que trata dos procedimentos operacio nais padrão 43 Procedimento operacional padrão O POP procedimento operacional padrão pode ser definido como um documento que determina como uma atividade tarefa ou procedimento deve ser realizado citando seus envolvidos responsáveis os materiais necessários para sua correta execução e as ações corretivas cabíveis que devem ser aplica das para os funcionários ou colaboradores que a desconsiderarem 83 Tópicos especiais de gestão de projetos de TI Na gerência de projetos em TI o primeiro passo é o levantamento da situação atual de um determinado processo envolvido no projeto Tal levanta mento tem como resultado o mapa de processos com seus respectivos cami nho principal caminhos alternativos e exceções O mapa de processos permite ao gestor compreender como as ativida des agregadoras de valor daquele processo estão interligadas e como ocorre o fluxo de dados e informações De posse desse conhecimento o gestor tem condições de determinar o que precisa ser controlado dentro do processo e o que não é relevante mediante a identificação de indicadores de controle e pontos de controle para o caso de auditoria Esses indicadores serão medidos em intervalos de tempo prédeterminados e apresentarão como resultado um gráfico de suas medições no decorrer do período As informações contidas nesse gráfico permitem ao gestor comparar os resultados da empresa ou departamento em questão com os resultados dos concorrentes ou mesmo com resultados espe rados definidos pela diretoria por exemplo Uma vez compreendida a diferença entre o resultado obtido e o resul tado esperado dos indicadores de controle o gestor pode determinar regras para a execução de determinados procedimentos com o intuito de melhorar o resultado medido pelo indicador e essas regras são justamente os POPs pois determinam um padrão de atuação para uma atividade específica Sendo assim as empresas passam a ter procedimentos operacionais padrão de aten dimento ao cliente procedimentos operacionais padrão de manutenção de veículo de troca de pneus de pósvenda de acondicionamento de produtos perecíveis de controle de estoque de definição de variáveis de sistema de nomenclatura de classes e objetos na programação etc Note que o POP pode definir padrões para toda e qualquer atividade da empresa desde a maneira como se deve fazer um café até como lançar um satélite ao espaço O cuidado deve ser tomado de maneira a não criar POPs para as atividades que não são relevantes ou não precisam ser controladas pois a criação do POP demanda tempo e seu controle medição de indicadores e tratamento das ações corretivas pode causar desconforto e constrangimento entre os funcionários caso o gestor não consiga convencêlos da importância desse controle Gerência de projetos em TI 84 Cada empresa pode criar seu próprio padrão de documento para o POP Os quadros 2 e 3 apresentam exemplos dos elementos que um procedimento operacional padrão contempla Quadro 2 Itens do procedimento operacional padrão Nome do POP Todo POP precisa ter um nome que o identifi que unicamente Exemplo procedimento ope racional padrão de atendimento ao cliente Data da criação do POP Deve indicar a data em que o POP foi criado Data da última alte ração do POP Deve conter a data em que o POP foi alterado pela última vez Responsável Deve identificar o nome ou cargo da pessoa que é responsável por verificar se o POP está sendo cum prido Essa é a pessoa responsável também por aplicar as ações corretivas definidas no POP Atividade crítica Define a lista de atividades que precisam ser seguidas e que garantem o sucesso na execu ção da atividade monitorada pelo POP Material utilizado Contém a lista de materiais necessários para a correta execução das atividades críticas e que devem estar dis poníveis para o funcionário responsável por executálas Manuseio do material Contém recomendações que devem ser seguidas de maneira a evitar que o material utilizado na execução das atividades definidas pelo POP seja danificado Ações corretivas1 Contém a descrição das punições que devem ser aplicadas ao funcionário que descumprir delibera damente as regras definidas pelas atividades crí ticas do POP ou pelo manuseio do material Fonte Elaborado pelo autor 1 Algumas empresas invertem o caráter punitivo das ações corretivas dando foco para as bo nificações e não para as penalizações Dessa maneira em vez de punir o funcionário que não realiza adequadamente a atividade ou descumpre a regra podendo gerar descontentamentos constrangimentos e desconfortos a empresa passa a bonificar os funcionários que seguem corretamente as regras definidas no POP 85 Tópicos especiais de gestão de projetos de TI Quadro 3 Exemplo de POP Nome Procedimento operacional padrão de nomenclatura de variáveis Data da criação 20072017 Data da última alteração 28072017 Responsável Líder de desenvolvimento da equipe Atividade crítica Para nomear as variáveis do software desenvolvido no projeto o programador deve seguir as seguintes regras Variáveis locais Inicia com a letra Z maiúscula seguida pelo caractere que define a tipologia da variável Devese utilizar o símbolo para variáveis inteiras para variáveis texto para variáveis de ponto flutuante para variáveis booleanas O terceiro caractere deve ser sempre o símbolo para sublinhado underline seguido do nome da variável inserido com a ini cial maiúscula e sempre que possível deve ser utilizado um nome que lembre a função ou o motivo de existir da variável Exemplo ZContador No exemplo a variável é inteira local e serve como contadora Variáveis globais Seguem a mesma regra que as variáveis locais mas em vez de iniciarem com a letra Z iniciam com a letra K Exemplo KNomeCliente Representa uma variável global do tipo texto e que armazena o nome do cliente Material utilizado Computador conectado em rede com os demais do departamento Login e senha de acesso cadastrados Manuseio do material Proibido comer ou beber enquanto utiliza o com putador O login e a senha de acesso são indivi duais e secretos não devendo ser divulgados Gerência de projetos em TI 86 Ações corretivas Como resultado da revisão de código realizada semanalmente pelo líder de equipe o programa dor será bonificado da seguinte maneira Sem erros 2 dias de almoço grátis na semana seguinte Até 10 erros 1 dia de almoço grátis na semana seguinte De 10 a 50 erros sem bonificação Acima de 50 erros advertência passí vel de desligamento após reincidência Fonte Elaborado pelo autor Essa é uma maneira de se montar um POP Conforme comentamos anteriormente cada empresa pode ter seu próprio modelo O importante é que ele garanta que o padrão estabelecido seja seguido Ampliando seus conhecimentos Para gerir projetos inovadores o gestor de TI precisa ter conhecimentos que vão além da sua área Ele também pre cisa ter flexibilidade para descentralizar as ações e integrar as atividades focando na polivalência dos funcionários como explica o texto a seguir Gestão de projetos inovadores MACHADO 2009 p 2930 A base de conhecimentos necessários ao desempenho da atividade de gerenciamento de projetos sobrepõe parcial mente as outras áreas de conhecimentos e tem área específica de conhecimentos e práticas relacionados com a profissão Dentre esses conhecimentos encontramse algumas técnicas especializadas para a programação de atividades de projetos como PERT Program Evaluation and Review Technique 87 Tópicos especiais de gestão de projetos de TI CPM Critical Path Method e sistemas de controle de custoscronograma O projeto conforme definição anterior possui como uma de suas principais características o fato de ser temporário cuja vida pode durar algumas semanas ou alguns anos necessi tando da hospedagem de uma organização que o cria for nece recursos presta serviços e o abriga sob sua responsabi lidade jurídica Para Fleury e Fleury 2005 a divisão rígida da organização do trabalho vem sendo questionada nos últimos anos tanto do ponto de vista do trabalho pelo seu caráter de alienação quanto pela ótica do capital pelo fato de não aproveitar ple namente as potencialidades do trabalhador A visão fordista taylorista do parcelamento das tarefas e alocação de operários especializados revelouse improdutiva Tal modelo apenas enfatizava o aumento de produção e funcionou a contento apenas porque foi implementada em um período de cresci mento econômico Como praticamente não havia problemas de demanda a preocupação com eficiência e qualidade era secundária Nos tempos atuais o enfoque é basicamente o oposto valorizandose as qualificações dos empregados no sentido de polivalência de atividades e quebra de hierarquia organizacional caracterizandose como paradigma toyotista destacado no quadro 1 Inovações organizacionais como o justintime e o controle de qualidade total geralmente estão associadas a estruturas gerenciais mais horizontalizadas e integradas em células Esta estrutura descentralizada típica para atuação do gerente de projetos objeto deste estudo favorece adaptações repenti nas e rápidas das atividades da empresa a um mercado e a um ambiente tecnológico em evolução constante Gerência de projetos em TI 88 Quadro 1 Mudanças nas qualificações dos trabalhadores Paradigma fordista Paradigma toyotista Funções especializadas Trabalhadores multifuncionais Qualificações estáveis Rápidas mudanças nas qualificações Relações fixas com tarefas e equipamentos Ênfase na flexibilidade e criatividade Relação estável entre qualificação e tecnologia Relação variável entre qualificação e tecnologia Modelo de aprendizado aprendiz versus profissional Educação continuada Fonte TIGRE Paulo B Gestão da Inovação 2006 O Quadro mostra que no paradigma da manufatura ape lidado de toyotista em oposição ao fordista os traba lhadores não são especializados em uma única função São treinados para serem polivalentes de forma a executar múl tiplas funções Tal característica oferece mais flexibilidade no cumprimento de tarefas diferenciadas e atende às crescentes exigências de tecnologias e processos integrados Atividades 1 Um processo com nenhum caminho alternativo é bom ou ruim para o gerente de projetos Por quê 2 Um processo com nenhuma exceção é bom ou ruim para o gerente de projetos Por quê 3 O que é um procedimento operacional padrão 4 Explique para que serve a ação corretiva no POP As áreas do conhecimento da gestão de projetos Neste capítulo em sua primeira parte enfatizaremos os aspectos mais importantes da gestão de projetos e suas áreas do conhecimento Na segunda parte abordaremos a gestão de escopo e detalharemos suas características Por fim na terceira parte apresentaremos alguns modelos de documentos utilizados na ges tão do escopo 5 Gerência de projetos em TI 90 51 Revisão de conceitos Para abordar as dez áreas de conhecimento tratadas pela metodologia ou modelo de melhores práticas de gestão de projetos adotada pelo Project Management Institute PMI precisamos relembrar rapidamente alguns con ceitos já estudados em capítulos anteriores Conforme visto no Capítulo 1 projeto é a unidade mínima de aplica ção de recursos que por intermédio de um conjunto integrado de atividades pretende transformar uma parcela da realidade diminuindo ou eliminando um deficit ou solucionando um problema PEREIRA TEIXEIRA 2014 Já para o Project Management Body of Knowledge PMBOK projeto é um esforço temporário empreendido para criar um produto serviço ou resul tado exclusivo E complementa que a natureza temporária dos projetos indica que eles têm um início e um término bem definidos PMI 2013 p 3 Ainda segundo essa mesma fonte um projeto pode criar 2 um produto que pode ser um componente de outro item um apri moramento de outro item ou um item final 2 um serviço ou a capacidade de realizar um serviço por exemplo uma função de negócios que dá suporte à produção ou distribuição 2 uma melhoria nas linhas de produtos e serviços por exemplo um projeto six sigma1 executado para reduzir falhas 2 um resultado como um produto ou documento por exemplo um projeto de pesquisa que desenvolve o conhecimento que pode ser usado para determinar se uma tendência existe ou se um novo pro cesso beneficiará a sociedade A gerência de projetos é a aplicação de conhecimentos habilidades e técnicas para projetar atividades que visam alcançar as necessidades e expecta tivas referentes ao projeto buscando o equilíbrio entre as demandas ou áreas concorrentes escopo tempo risco e qualidade PMI 2013 p 4 1 Six sigma ou seis sigma metodologia para melhoramento da qualidade de processos MASSOT 2008 91 As áreas do conhecimento da gestão de projetos Para Sousa 2007 p 25 o gerenciamento do projeto consiste em todos os processos métodos ferramentas e conceitos que são utilizados para con duzir o projeto desde seu início até o seu fim entregando os resultados e atingindo os objetivos A metodologia adotada pelo PMBOK PMI 2013 como modelo para as melhores práticas na gestão de projetos identifica e trata das dez áreas do conhecimento ou demandas concorrentes que necessitam de atenção trans parência e equilíbrio para que um projeto tenha chances reais de ser bem realizado e sucedido E cada uma dessas dez áreas estão distribuídas em cinco fases ou grupos de processos de gerenciamento de projeto iniciação planeja mento execução controle e encerramento conforme apresentado na figura a seguir Figura 1 Grupo de processos de gerenciamento de projetos Processos de iniciação Processos de encerramento Processos de monitoramento e controle Entrar em fase inciar projeto Sair de fase encerrar projeto Processos de planejamento Processos de execução Fonte PMI 2013 p 49 Esses cinco grupos têm dependências claras e em geral segundo o PMBOK PMI 2013 p 419 são executados em quaisquer projetos e pos suem um alto grau de integração entre si A seguir apresentamos um resumo das dez áreas do conhecimento tra tadas pela metodologia adotada pelo PMI e como elas se distribuem nas fases ou grupos de processos apresentados na Figura 1 Gerência de projetos em TI 92 511 Gerência de integração do projeto A gerência de integração de um projeto deve ter a função de combinar todas as outras áreas do conhecimento e respectivos processos para formar o todo do projeto de modo a manter o seu equilíbrio a integridade e coesão De acordo com o PMI 2013 o gerenciamento da integração inclui processos e atividades para identificar definir combinar unificar e coordenar os vários processos e atividades dentro do grupo de processos de gerencia mento do projeto PMI 2013 p 62 O quadro a seguir apresenta uma visão geral dos processos do gerencia mento da integração do projeto em relação às fases ou grupos de processos do projeto Quadro 1 Processos do grupo de gerenciamento de integração do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação Desenvolver o termo de abertura do projeto Planejamento Desenvolver o plano de gerenciamento do projeto Execução Orientar e gerenciar a execução do projeto Controle Monitorar e controlar o trabalho do projeto Realizar o controle integrado de mudanças Encerramento Encerrar o projeto ou fase Fonte PMI 2013 p 61 Adaptado 512 Gerência do escopo do projeto Podemos entender que o escopo de um projeto deve definir os objetivos que o projeto pretende atingir o limite de sua abrangência qual o seu alvo propósito desígnio ou finalidade Esse assunto será detalhado mais adiante 513 Gerência do tempo do projeto A gerência do tempo do projeto é responsável por tratar cuidar ou aten der o prazo ou demora em se realizar todas as atividades e tarefas envolvidas 93 As áreas do conhecimento da gestão de projetos em cada processo Sendo mais formal o PMBOK PMI 2013 p 140 des taca que o gerenciamento do tempo do projeto inclui os processos necessários para gerenciar o término pontual do projeto O Quadro 2 fornece uma visão geral dos processos de gerenciamento do tempo do projeto Quadro 2 Processos do grupo de gerenciamento do tempo do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento do cronograma Definir as atividades Sequenciar as atividades Estimar os recursos das atividades Estimar a duração das atividades Desenvolver o cronograma Execução vazio Controle Controlar o cronograma Encerramento vazio Fonte PMI 2013 p 422 Adaptado 514 Gerência dos custos do projeto A gerência dos custos do projeto tem por objetivo controlar quanto o projeto vai custar ou quanto os clientes ou patrocinadores vão precisar pagar para ter o resultado do projeto funcionando conforme definido pelo escopo do projeto Segundo o PMBOK PMI 2013 p 199 estimar os custos é o pro cesso de desenvolvimento de uma estimativa dos recursos monetários necessários para executar as atividades do projeto O Quadro 3 apresenta os processos de gerenciamento dos custos do projeto com relação às fases ou grupos de processos Gerência de projetos em TI 94 Quadro 3 Processos do grupo de gerenciamento dos custos do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento dos custos Estimar os custos Determinar o orçamento Execução vazio Controle Controlar os custos Encerramento vazio Fonte PMI 2013 p 422 Adaptado 515 Gerência da qualidade do projeto A gerência da qualidade do projeto deve primar pela excelência na execu ção das tarefas de cada atividade de cada processo envolvido O PMBOK PMI 2013 p 226 destaca que 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 satis faça às necessidades para as quais foi empreendido O Quadro 4 fornece uma visão geral dos processos de gerenciamento da qualidade do projeto Quadro 4 Processos do grupo de gerenciamento da qualidade do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento da qualidade Execução Realizar a garantia da qualidade Controle Controlar a qualidade Encerramento vazio Fonte PMI 2013 p 422 Adaptado 95 As áreas do conhecimento da gestão de projetos 516 Gerência de recursos humanos do projeto Recursos humanos são os conjuntos de meios pessoas disponíveis para serem utilizados no projeto O PMBOK PMI 2013 p 254 destaca que o gerenciamento dos recursos humanos do projeto inclui os processos que orga nizam gerenciam e guiam a equipe do projeto enfatizando que a equipe do projeto consiste em pessoas com papéis e responsabilidades designados para completar o projeto O Quadro 5 mostra uma visão geral dos processos de gerenciamento dos recursos humanos do projeto para cada uma das fases Quadro 5 Processos do grupo de gerenciamento dos recursos humanos do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento dos recursos humanos Execução Contratar e mobilizar a equipe do projeto Desenvolver a equipe do projeto Gerenciar a equipe do projeto Controle vazio Encerramento vazio Fonte PMI 2013 p 422 Adaptado 517 Gerência da comunicação do projeto A gerência da comunicação de projeto deve ser responsável por coorde nar a transmissão da informação e informar aos membros do projeto sobre as notícias referentes a ele Para o PMBOK o gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as informações do projeto sejam planejadas coletadas criadas distribuídas armazenadas recupe radas gerenciadas controladas monitoradas e finalmente dispostas de maneira oportuna e apropriada PMI 2013 p 287 Gerência de projetos em TI 96 O Quadro 6 fornece uma visão geral dos processos do gerenciamento das comunicações do projeto Quadro 6 Processos do grupo de gerenciamento das comunicações do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento das comunicações Execução Gerenciar as comunicações Controle Controlar as comunicações Encerramento vazio Fonte PMI 2013 p 422 Adaptado 518 Gerência dos riscos do projeto O PMBOK PMI 2013 p 309 destaca que o gerenciamento dos riscos do projeto inclui os processos de identificação análise e planejamento de respostas e controle de riscos de um projeto A mesma fonte enfatiza que o objetivo do gerenciamento dos riscos de um projeto é aumentar a probabilidade e o impacto dos eventos positivos e reduzir a probabilidade e o impacto dos eventos negativos O Quadro 7 apresenta uma visão geral dos processos de gerenciamento dos riscos do projeto Quadro 7 Processos do grupo de gerenciamento dos riscos do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento dos riscos Identificar os riscos Realizar a análise qualitativa dos riscos Realizar a análise quantitativa dos riscos Planejar as respostas aos riscos Execução vazio 97 As áreas do conhecimento da gestão de projetos Grupo de processos Processos de gerenciamento de projeto Controle Controlar os riscos Encerramento vazio Fonte PMI 2013 p 422 Adaptado 519 Gerência das aquisições do projeto No PMBOK PMI 2013 p 355 o gerenciamento das aquisições do projeto inclui os processos necessários para comprar ou adquirir produtos serviços ou resultados externos à equipe do projeto O Quadro 8 apresenta uma visão geral dos processos do gerenciamento das aquisições do projeto de acordo com a fase do projeto Quadro 8 Processos do grupo de gerenciamento das aquisições do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação vazio Planejamento Planejar o gerenciamento das aquisições Execução Conduzir as aquisições Controle Controlar as aquisições Encerramento Encerrar as aquisições Fonte PMI 2013 p 422 Adaptado 5110 Gerência das partes interessadas do projeto Conforme o PMBOK PMI 2013 p 391 o gerenciamento das partes interessadas do projeto inclui os processos exigidos para identificar todas as pessoas grupos ou organizações que podem impactar ou serem impactados pelo projeto além de analisar as expectativas das partes interessadas e seu impacto no projeto e desenvolver estratégias de gerenciamento apropriadas para o engajamento eficaz desses grupos nas decisões e execução do projeto O Quadro 9 fornece uma visão geral dos processos de gerenciamento das partes interessadas do projeto Gerência de projetos em TI 98 Quadro 9 Processos do grupo de gerenciamento das partes interessadas do projeto Grupo de processos Processos de gerenciamento de projeto Iniciação Identificar as partes interessadas Planejamento Planejar o gerenciamento das partes interessadas Execução Gerenciar o engajamento das partes interessadas Controle Controlar o engajamento das partes interessadas Encerramento vazio Fonte PMI 2013 p 422 Adaptado Com isso finalizamos a revisão dos conceitos necessários e fizemos uma apreciação geral das dez áreas do conhecimento Faremos agora uma apre sentaçãodiscussão mais detalhada de algumas das áreas do conhecimento iniciando com a gestão do alvo do projeto isso é o tópico que trata sobre técnicas e cuidados que o gestor de projetos deve ter para que o objetivo o motivo de existir do projeto seja atingido no prazo e custo acordados 52 Gestão do escopo do projeto Para desenvolver um produto serviço ou resultado que atinja as expec tativas do cliente e mantenha o equilíbrio entre o custo previsto e o custo real e entre o tempo previsto e o tempo real do projeto o gestor do projeto precisa definir e defender com unhas e dentes a abrangência do projeto Caso contrário itens e mais itens serão inseridos no escopo do projeto e ele nunca será finalizado no prazo e no custo previstos e mais ainda o resultado dificilmente agradará ao cliente ou patrocinador Para o PMI O gerenciamento do escopo do projeto inclui os procedimentos necessários para assegurar que o projeto inclui todo o trabalho neces sário e apenas o necessário para terminar o projeto com sucesso Está relacionado principalmente com o a definição e o controle do que está e do que não está incluso no projeto PMI 2013 p 105 O Quadro 10 fornece uma visão geral dos processos de gerenciamento do escopo do projeto em relação às fases ou grupos de processo do projeto 99 As áreas do conhecimento da gestão de projetos Quadro 10 Processos do grupo de gerenciamento do escopo do projeto Grupo de processos Processos de gerenciamento do escopo projeto Iniciação vazio Planejamento Planejar o gerenciamento do escopo Coletar os requisitos Definir o escopo Criar o EAP Execução vazio Controle Validar o escopo Controlar o escopo Encerramento vazio Fonte PMI 2013 p 422 Adaptado Como se pode perceber analisando os itens apresentados no Quadro 10 quatro dos seis processos estão alocados na fase de planejamento do projeto e os dois restantes na fase de controle A Figura 2 a seguir tem a função de relembrar as fases do projeto des tacando as fases de planejamento e de controle Figura 2 Processos do gerenciamento de escopo versus fases ou etapas do projeto Planejamento Saídas do gerenciamento do projeto Encerra mento do projeto Termo de abertura do projeto Início do projeto Arquivamento dos documentos do projeto Execução do trabalho Plano de gerencia mento do projeto Nível de custos e pessoal Entregas aceitas Fase de controle Tempo Fonte PMBOK 2013 p 39 Adaptado Gerência de projetos em TI 100 É importante lembrar que o PMI trata cada área do conhecimento como uma sequência de processos e que cada processo precisa de pelo menos uma entrada e tem um processamento inerente às atividades daquele processo e uma ou mais saídas conforme apresentado na Figura 3 Figura 3 Processo Gerência do escopo do projeto Entradas Saídas Fonte CAMPOS LIMA 2012 p 1 Adaptado Com base nessa figura podemos analisar os dados apresentados na Figura 2 em que temos o primeiro processo com o planejamento do geren ciamento do escopo que gera como resultado um documento determinando como o escopo do projeto será definido validado e controlado Segundo o PMBOK PMI 2013 p 428 o principal benefício desse processo é o for necimento de orientação e instruções sobre como o escopo será gerenciado ao longo de todo o processo Suas entradas e saídas são apresentadas na Figura 4 Figura 4 Entradas e saídas do processo de planejar o gerenciamento do escopo Entradas Planejar o gerenciamento do escopo Saídas 1 Plano de gerenciamento do projeto 2 Termo de abertura do projeto 3 Fatores ambientais da empresa 4 Ativos de processos organiza cionais 1 Plano de gerencia mento de escopo 2 Plano de gerencia mento dos requisitos Fonte PMI 2013 p 428 Adaptada O segundo processo coletar os requisitos tem como entrada os docu mentos gerados no primeiro processo e suas atividades têm a função de deter minar documentar e gerenciar as necessidades e requisitos das partes interes sadas a fim de atender aos objetivos do projeto O resultado é um documento contendo todos os requisitos e necessidades apontadas pelos interessados e 101 As áreas do conhecimento da gestão de projetos envolvidos no projeto como sendo indispensáveis para o sucesso deste Segundo o PMBOK PMI 2013 p 429 o principal benefício desse pro cesso é o fornecimento da base para definição e gerenciamento do escopo do projeto incluindo o escopo do produto A Figura 5 apresenta esquematica mente as entradas e saídas desse processo Figura 5 Entradas e saídas do processo de coletar os requisitos Entradas Coletar os requisitos Saídas 1 Plano de gerenciamento de escopo 2 Plano de gerenciamento de requi sitos 3 Plano de gerenciamento das partes interessadas 4 Termo de abertura do projeto 5 Registro das partes interessadas 1 Documentação dos requisitos 2 Matriz de rastreabili dade dos requisitos Fonte PMI 2013 p 429 Adaptada O terceiro processo definir o escopo tem como função justamente ter uma descrição detalhada do projeto e do produto serviço ou resultado que almeja produzir O principal benefício desse processo segundo PMBOK PMI 2013 p 429 é que ele descreve os limites do projeto serviço ou resultados ao definir quais dos requisitos coletados serão incluídos e quais serão excluídos do escopo do projeto A Figura 6 representa esquematica mente as entradas e saídas desse processo Figura 6 Entradas e saídas do processo de definir escopo Entradas Definir escopo Saídas 1 Plano de gerenciamento do escopo 2 Termo de abertura do projeto 3 Documentação dos requisitos 4 Ativos de processos organizacionais 1 Declaração do escopo do projeto 2 Atualização nos docu mentos do projeto Fonte PMI 2013 p 429 Adaptada Gerência de projetos em TI 102 A quarta parte ou quarto processo da gerência de escopo do projeto é o de criar EAP estrutura analítica do projeto2 cuja função é a de subdividir a descrição detalhada do produto serviço ou resultado que o projeto objetiva implementar em entregas ou componentes menores e mais facilmente geren ciáveis Segundo o PMI PMI 2013 p 431 o principal benefício desse processo é o fornecimento de uma visão estruturada do que deve ser entregue Figura 7 Entradas e saídas do processo de criar EAP Entradas Criar EAP Saídas 1 Plano de gerenciamento do escopo 2 Declaração do escopo do projeto 3 Declaração dos requisitos 4 Fatores ambientais da empresa 5 Ativos dos processos organizacionais 1 Linha de base do escopo 2 Atualização nos docu mentos do projeto Fonte PMI 2013 p 430 Adaptada O quinto processo validar escopo tem como objetivo formalizar cada uma das entregas ou componentes definidos no processo anterior O principal benefício desse processo segundo o PMBOK PMI 2013 p 452 é que ele proporciona objetividade ao processo de aceitação e aumenta a probabilidade da aceitação final do produto serviço ou resultado É importante destacar que esse processo não está mais na fase de planejamento do projeto mas sim na fase de controle e monitoramento Figura 8 Entradas e saídas do processo de validar escopo Entradas Validar Escopo Saídas 1 Plano de gerenciamento do projeto 2 Documentação dos requisitos 3 Matriz de rastreabilidade de requi sitos 4 Entrega verificada 5 Dados de desempenho do projeto 1 Entrega aceitas 2 Solicitações de mu danças 3 Informações sobre o desempenho do trabalho 4 Atualizações nos do cumentos do projetos Fonte PMI 2013 p 452 Adaptada 2 A EAP é uma decomposição hierárquica do escopo total do trabalho a ser executado pela equipe do projeto a fim de alcançar os objetivos do projeto e criar as entregas requeridas A EAP organiza e define o escopo total do projeto e representa o trabalho especificado na atual declara ção do escopo do projeto aprovada PMI 2013 p 125 103 As áreas do conhecimento da gestão de projetos E por último o sexto processo ou sexta parte do processo de gerência de escopo do projeto controlar escopo que também se encontra na fase de monitoramento e controle do projeto objetiva monitorar o andamento do escopo do projeto Nisso se encontra o trabalho contínuo do gestor do projeto atendendo o escopo para que ele não seja significativamente alterado em decorrência das eventuais mudanças durante o decorrer do projeto Figura 9 Entradas e saídas do processo de controlar escopo Entradas Controlar escopo Saídas 1 Plano de gerenciamento do projeto 2 Documentação dos requisitos 3 Matriz de rastreabilidade de requi sitos 4 Dados de desempenho do trabalho 5 Ativos de processos organizacionais 1 Informações sobre o desempenho do trabalho 2 Solicitação de mudan ças 3 Atualização do plano de gerenciamento do projeto 4 Atualização nos docu mentos do projeto 5 Atualizações nos ativos de processos organizacionais Fonte PMI 2013 p 454 Adaptada 53 Documentos Apresentamos na sequência alguns modelos dos documentos citados anteriormente nas figuras 4 a 9 tendo por base Trentim 20123 Figura 10 Documento 1 plano de gerenciamento de projeto Título do projeto Data de início Número Gerente Patrocinador Cliente 3 Este capítulo contempla apenas os primeiros seis documentos Os demais itens serão con templados oportunamente nos próximos capítulos Gerência de projetos em TI 104 Documentos anexados Termo de abertura do projeto Equipe de planejamento Plano de gerenciamento de escopo e de mudança Declaração do escopo do projeto Estrutura analítica do projeto Plano de gerenciamento de tempo Rede de atividades Cronograma Plano de gerenciamento de custos Orçamento Plano de gerenciamento de qualidade Plano de recursos humanos Plano de gerenciamento das comunicações Plano de gerenciamento das respostas aos riscos Análise de riscos Plano de aquisições Documentos de encerramento Lições aprendidas Fechamento de contratos Fechamento administrativo OBS Relacionar quaisquer observações relevantes para o entendimento do planejamento Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data Assinatura do cliente Data Fonte Elaborada pelo autor 105 As áreas do conhecimento da gestão de projetos Figura 11 Documento 2 termo de abertura do projeto Título do projeto Data de início Número Gerente Patrocinador Cliente 1 Objetivo do projeto Descrever aqui o que a organização pretende obter com o resultado do projeto 2 Demanda de negócio Descrever por que o projeto está sendo realizado apresen tando a justificativa e o alinhamento estratégico 3 O que é o escopoo que não é o escopo do projeto Descrever aqui sucintamente os subprodutos a serem entregues e os que não serão 4 Interessados Mencionar os principais envolvidos interna ou externamente com o projeto ou aqueles que serão afetados positiva ou negativamente com sua execução 5 Interface com projetos existentes Mencionar outros projetos que possam interfe rir de alguma forma no seu desenvolvimento 6 Prazo estimado para a conclusão do projeto Definir aqui uma estimativa de prazo para a entrega do trabalho 7 Orçamento estimado para a conclusão do projeto Definir aqui uma estimativa de custo para a entrega do trabalho 8 Equipe básica Citar aqui os especialistas que inicialmente ajuda rão a compreender e planejar o projeto 9 Restrições Mencionar os fatores que podem limitar as opções da equipe de projeto Gerência de projetos em TI 106 10 Premissas Mencionar os fatores que para fins de planejamento serão considerados verdadeiros 11 Gerente do projeto Indicar o gerente de projeto suas principais atribuições e seu nível de autoridade Assinatura do patrocinador Data Assinatura da alta administração Data Fonte Elaborada pelo autor Figura 12 Documento 3 equipe de planejamento do projeto Título do projeto Data de início Número Gerente Patrocinador Cliente 1 Equipe e atribuições Relacionar aqui os membros da equipe de planejamento do pro jeto suas respectivas habilidades e titulações Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data 107 As áreas do conhecimento da gestão de projetos Assinatura do cliente Data Fonte Elaborada pelo autor Figura 13 Documento 4 plano de gerenciamento de escopo e de mudanças Título do projeto Data de início Número Gerente Patrocinador Cliente 1 Aspectos gerais Descrever os aspectos gerais do gerenciamento de escopo de mudanças Deve ser incluído o procedimento para coletar requisitos Deve ser incluído o procedimento para solicitação de mudanças análise dos impactos da mudança e confecção de relatório para aprovação da mudança pelo cliente e pelo patrocinador Criar documento de solicitação de mudança e de aprovação como anexo ao final do plano de gerenciamento de projeto 2 Processo de gerenciamento de escopo e de mudanças Descrever o processo a ser seguido para definir deta lhar e controlar o escopo fluxograma Descrever o processo para tratar as mudanças fluxograma 3 Comitê de controle de mudança Relacionar as pessoas responsáveis por analisar as solicitações de mudança 4 Processo de gerenciamento de configuração Descrever como será feito o controle dos itens relacionando a forma de arma zenamento acesso registro de alterações e identificação das versões Gerência de projetos em TI 108 Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data Assinatura do cliente Data Fonte Elaborada pelo autor Figura 14 Documento 5 declaração do escopo do projeto Título do projeto Data de início Número Gerente Patrocinador Cliente 1 Resumo do projeto Introdução e justificativa Descrição da situação que gerou a necessidade do projeto o motivo pelo qual ele foi iniciado expectativas para com os resultados do projeto e possíveis soluções Descrição do produto ou serviço do projeto solução para o problema contextualizado Ressaltar alinhamento estratégico do projeto e justificativa empre sarial o que a empresa vai ganhar executando o projeto 2 Objetivo do projeto Descrição do que se espera atingir com a implemen tação do projeto seu produto ou serviço Fatores de sucesso e critérios de êxito 3 Metas do projeto 109 As áreas do conhecimento da gestão de projetos As metas do projeto são atividades que devem ser concluídas para que os objetivos do projeto sejam atingidos Ao descrever uma meta certifiquese de que ela seja clara e bem definida Metas Smart 2 Específica clara e concisa as pessoas que a lerem devem entender exatamente o que se pretende atingir 2 Mensurável as metas precisam ser medidas verificadas deve ser possível determinar se a meta foi atingida ou não 2 Acordada as metas devem ser acordadas entre os stakeholders de modo a garantir que todos estão trabalhando na mesma direção 2 Realista obviamente as metas devem ser realistas não podem ser inatingíveis 2 Tempo limitado toda meta deve ter um prazo para ser atingidaconcluída 4 Lista completa de entregas e requisitos Descrição de todas as entregas do projeto Descrição de todos os requisitos do projeto 5 Exclusões e escopo Descrever o que não faz parte do escopo do projeto 6 Estimativa de tempo e custo Estimativa de tempo e custo do projeto incluir cronograma e orçamentos preliminares 7 Premissas restrições e riscos Inserir lista de premissas Inserir lista de restrições Inserir lista de riscos identificados 8 Critérios de aceitação do produtoserviço Descrever o modo de avaliação e aceitação desses resultados pelos stakeholders incluir formulários de aceitação com checklist de critérios para verificação Gerência de projetos em TI 110 Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data Assinatura do cliente Data Fonte Elaborada pelo autor Figura 15 Documento 6 estrutura analítica do projeto Título do projeto Data de início Número Gerente Patrocinador Cliente 1 Estrutura analítica do projeto Inserir a estrutura analítica do projeto EAP em modo gráfico para ter uma visão do projeto e de suas entregas principais 2 Dicionário da EAP O dicionário da EAP deverá descrever detalhadamente cada uma das entregas até o menor nível de pacote de trabalho em que é pos sível estimar os recursos e a duração com maior precisão Fonte Elaborada pelo autor 111 As áreas do conhecimento da gestão de projetos Ampliando seus conhecimentos O texto a seguir apresenta mais detalhes sobre a técnica de EAP Estrutura Analítica de Projeto e sua importância para os gerentes de projetos Principais agrupamentos encontrados em uma EAP LARSON GRAY 2016 p 90 Após o escopo e as entregas terem sido identificados o trabalho do projeto pode ser subdividido em elementos de trabalho cada vez menores O resultado desse processo hie rárquico é chamado de estrutura analítica do projeto EAP O uso da EAP ajuda a assegurar aos gerentes de projetos que todos os produtos e elementos de trabalho sejam identifica dos integrar o projeto com a estruturação atual e estabelecer uma base para controle Basicamente a EAP é um esboço do projeto com diferentes níveis de detalhe A Figura mostra os principais agrupamentos comumente usa dos para desenvolver uma EAP hierárquica A EAP começa com o projeto como a entrega final Primeiro identificamse as principais entregassistemas do trabalho do projeto então as subentregas necessárias para realizar os trabalhos maiores são definidas O processo é repetido até que o nível de detalhe das subentregas seja pequeno o suficiente para ser gerenciá vel com a possibilidade de associar uma pessoa como res ponsável Essa subentrega é dividida em pacotes de trabalho Como a menor subentrega geralmente compreende diversos pacotes de trabalho estes são agrupados por tipo de trabalho Gerência de projetos em TI 112 por exemplo design e testes Os agrupamentos dentro de uma subentrega são chamados de contas de custo Esse agru pamento facilita um sistema de monitoramento de andamento do projeto por trabalho custo e responsabilidade Figura Composição hierárquica da EAP Projeto Entrega Subentrega Menor subentrega Conta de custo Pacote de trabalho Nível Composição hierárquica Concluir projeto 1 2 3 5 4 Principais entregas Subentregas de suporte Menor nível de responsabilidade gerencial Agrupamento dos pacotes de trabalho para monitorar pro gresso e responsabilidade Atividades de trabalho identificáveis Descrição Esta composição agrupa os pacotes de trabalho por tipo de trabalho dentro de uma entrega possibilitando a atribuição de responsabilidades a uma unidade organizacional 113 As áreas do conhecimento da gestão de projetos Atividades 1 O que é escopo 2 O que é EAP e para que serve 3 Desenhe um fluxograma que represente os processos de gerenciamen to do escopo do projeto 4 No documento da declaração do escopo do projeto que itens devem ser contemplados no objetivo do projeto Gestão de tempo e recursos humanos Trataremos na primeira parte deste capítulo sobre o crono grama e mais especificamente sobre a gestão do tempo do projeto e aprenderemos quais os prérequisitos necessários para se montar um cronograma que seja o mais próximo possível de algo realizável Na segunda parte falaremos sobre a gestão de recursos humanos e as habilidades necessárias para que a equipe execute as atividades previstas no cronograma de maneira adequada e conforme o pre visto Já na terceira parte apresentaremos dois temas muitos impor tantes para o entendimento da gestão do tempo do projeto e para a montagem do cronograma E por fim trataremos do conceito de linha de base conceito importantíssimo para o entendimento da relação entre o previsto e o realizado em qualquer atividade do 6 Gerência de projetos em TI 116 projeto e de alguns modelos de documentos importantes utilizados pelas áreas do conhecimento tratadas no capítulo Ao final do capítulo você será capaz de entender a importância da gestão do tempo e dos recursos humanos do projeto e perceber quantas variáveis estão envolvidas no que parecia o simples ato de estimar o tempo de uma atividade do projeto 61 Cronograma Conforme verificamos no capítulo anterior o gerenciamento do tempo do projeto inclui os processos necessários para gerenciar o término pontual do projeto Seus processos são apresentados no Quadro 1 segundo o PMBOK PMI 2013 p 141 Quadro 1 Lista de processos do gerenciamento do tempo do projeto Grupo de processos Processos de gerenciamento do tempo projeto Iniciação vazio Planejamento Planejar o gerenciamento do cronograma Definir atividades Sequenciar as atividades Estimar os recursos das atividades Estimar as durações das atividades Desenvolver o cronograma Execução vazio Controle Controlar o cronograma Encerramento vazio Fonte PMI 2013 p 422 Adaptado Assim como foi verificado para os processos de gestão do escopo do projeto os processos da gestão do tempo do projeto acontecem nas etapas de planejamento e de controle Também é importante destacar que seis dos sete itens relacionados fazem referência a um item na verdade uma ferramenta de planejamento e controle denominado de cronograma Sobre o cronograma é importante destacar que 117 Gestão de tempo e recursos humanos O objetivo do cronograma é relacionar as atividades a serem executa das e o tempo previsto para sua realização Em termos gerenciais isso permite que se faça um esforço no sentido de a identificar as ativi dades e o tempo necessário para sua execução b estimar o tempo em face dos recursos disponíveis c analisar a possibilidade de superpor atividades executandoas em paralelo e d verificar a dependência entre as atividades TENÓRIO 2005 p 44 Vale destacar que um único item o quarto não trata diretamente do plano do projeto mas de estimar os recursos necessários para executar as atividades definidas pelo escopo do projeto gestão do escopo do projeto Vamos analisar cada um desses processos desde o planejamento do gerencia mento do cronograma passando pela definição e o sequenciamento de suas atividades bem como a definição dos recursos e do prazo para cada uma até finalmente termos todos os elementos para montar um cronograma ade quado ao projeto e também à capacidade de controlálo 611 Planejar o gerenciamento do cronograma O cronograma é uma ferramenta gráfica de planejamento e controle do plano do projeto conforme vimos anteriormente Tendo isso em conta o presente processo tem a função clara de definir as regras para o gerenciamento dessa ferramenta pois como se pode supor não é qualquer funcionário que pode alterar dados no cronograma nem mesmo esse controle pode ser alte rado ao bel prazer de qualquer um E em caso de alteração como se deve proceder Onde será armazenado o histórico das alterações Essas e outras questões precisam ser respondidas Como tratado pelo PMBOK esse processo tem o intuito de estabelecer técnicas políticas e métodos para de forma adequada acompanhar a evolução e o desenvolvimento do projeto e atualizar a documentação que representa essa evolução e desenvolvimento Ou ainda esse planejamento do gerenciamento do cronograma é o processo de estabelecer as políticas os procedimentos e a documentação para planejamento desenvolvimento gerenciamento e execu ção e controle do cronograma do projeto PMI 2013 p 431 É muito importante perceber que não estamos gerando o cronograma mas sim um documento que define como iremos gerenciálo Nesse momento do projeto o cronograma sequer existe Gerência de projetos em TI 118 A Figura 1 apresenta esquematicamente o primeiro dos sete processos de gerenciamento do cronograma com suas respectivas entradas e saídas Figura 1 Processo planejar o gerenciamento do cronograma1 Entradas Planejar o gerenciamento do cronograma Saídas 1 Plano de gerenciamento do projeto 2 Termo de abertura do projeto 3 Fatores ambientais da empresa 4 Ativo de processos organizacionais 1 Plano de gerencia mento do cronograma Fonte PMI 2013 p 431 Adaptado Uma vez planejado como deve ser realizado o controle do plano do pro jeto cronograma fazse necessário definir as atividades que deverão ser exe cutadas para que o objetivo definido pelo escopo do projeto seja atingido de acordo com o prazo e o custo determinados 612 Definir as atividades Um cronograma tem por função organizar um conjunto de atividades ordenandoas de forma que elas possam atingir o objetivo determinado para os processos do projeto Sendo assim um dos primeiros passos para a gestão efetiva do tempo e do cronograma do projeto é saber o que ou quais são as atividades contempladas no processo O PMBOK PMI 2013 p 432 destaca que o processo de definir as atividades trata da identificação e documentação das ações específicas a serem realizadas para produzir as entregas do projeto Ainda segundo a mesma fonte o principal benefício desse processo é permitir a divisão do objetivo 1 Na seção Ampliando seus conhecimentos deste capítulo apresentamos um exemplo do modelo do plano de gerenciamento do tempo do projeto 119 Gestão de tempo e recursos humanos do projeto em pequenos itens os quais podem ser estimados custo e prazo e programados enfim podem ser executados e monitorados durante a exe cução do projeto É importante reparar que para a execução desse processo é necessá rio ter como entrada a linha de base do escopo e o plano de gerenciamento do cronograma resultado do primeiro processo Como saída desse processo temos a lista de atividades do projeto os atributos ou características das ati vidades que devem ser executadas bem como a lista de marcos do projeto conforme podemos verificar na Figura 2 Figura 2 Processo de definir atividades Entradas Definir as atividades Saídas 1 Plano de gerenciamento do cronograma 2 Linha de base do escopo 3 Fatores ambientais da empresa 4 Ativo de processos organizacionais 1 Lista de atividades 2 Atributos das ativi dades 3 Lista de marcos Fonte PMI 2013 p 432 Adaptado A lista de atividades é uma lista abrangente que inclui todas as atividades do cronograma necessárias no projeto sendo que cada uma deve ter um título exclusivo que descreva o seu lugar no cronograma Já os atributos das atividades são as características que devem estar vin culadas a cada atividade para que ela seja executada sem problemas tais como tempo de execução esperado recursos necessários para sua execução prére quisitos précondições e póscondições Por fim temos a lista de marcos que determinada cada ponto ou evento significativo do projeto indicando se o marco é obrigatório tais como os exigidos no contrato ou opcional Gerência de projetos em TI 120 Nesse momento já temos o plano de gerenciamento do cronograma e a lista de atividades que devem ser executadas com seus respectivos atributos bem como os marcos que devem ser observados no decorrer do projeto Isso posto é chegado o momento de sequenciar essas atividades isso é definir a ordem em que essas atividades devem ser executadas 613 Sequenciar as atividades Segundo o PMBOK PMI 2013 p 432 esse é o processo de identi ficação e documentação dos relacionamentos entre as atividades do projeto e tem como principal benefício definir a sequência lógica do trabalho a fim de se obter o mais alto nível de eficiência na execução do projeto mesmo diante de suas restrições Esse processo está representado esquematicamente na Figura 3 Figura 3 Processo de sequenciar atividades Entradas Sequenciar as atividades Saídas 1 Plano de gerenciamento do cronograma 2 Lista de atividades 3 Atributos das atividades 4 Lista de marcos 5 Especificação do escopo do projeto 6 Fatores ambientais da empresa 7 Ativos de processos organiza cionais 1 Diagrama de rede do cronograma do projeto 2 Atualização dos docu mentos do projeto Fonte PMI 2013 p 153 Adaptado Note que os itens 2 3 e 4 relacionados na entrada desse processo são as saídas do processo anterior de definir atividades Outro ponto importante a destacar com relação às entradas é que para o correto sequenciamento das 121 Gestão de tempo e recursos humanos atividades são necessários também o plano de gerenciamento do cronograma item 1 e a especificação do escopo do projeto item 5 Já no que se refere às saídas temos o diagrama de redes do cronograma do projeto que conforme destaca Silva 2015 é uma ferramenta utilizada de maneira a sequenciar as atividades e destacar o caminho crítico do projeto sendo que este último serve para determinar o caminho com a maior duração isto é a sequência de atividades sem folga que determina a duração do projeto Tão importante quanto esse processo que tem a função de sequenciar as atividades do projeto é o próximo que trata da identificação dos recursos e da duração necessárias para a correta execução de cada atividade do projeto 614 Estimar os recursos e a duração das atividades Já identificamos e sequenciamos as atividades que devem ser realizadas para que o projeto atinja seu objetivo Nessa etapa precisamos definir qual equipe de funcionários vai executar as atividades quais recursos de infraes trutura serão necessários para a execução dessas atividades e com base nesses dados estimar a duração de cada atividade É importante ressaltar que a qualidade e a quantidade de recursos dis ponibilizados para a realização de determinada atividade influenciam direta mente na duração e no custo necessários para a sua realização Para o PMBOK PMI 2013 p 160 o principal benefício do processo de estimativa de recursos é identificar o tipo a quantidade e as caracterís ticas dos recursos exigidos para a realização de uma atividade permitindo assim estimativas de custo e tempo mais exatas baseadas na estrutura ana lítica de recursos2 A Figura 4 apresenta as entradas e saídas do processo de estimativa de recursos 2 Estrutura analítica dos recursos é uma representação hierárquica dos recursos por categoria e tipo PMI 2013 p 165 Gerência de projetos em TI 122 Figura 4 Processo de estimar recursos das atividades Entradas Estimativa de recursos Saídas 1 Plano de gerenciamento do cronograma 2 Lista de atividades 3 Atributos das atividades 4 Calendário dos recursos 5 Registro dos riscos 6 Estimativas do custo das ati vidades 7 Fatores ambientais da empresa 8 Ativos de processos organiza cionais 1 Registro de recursos das atividades 2 Estrutura analítica de recursos 3 Atualização dos docu mentos do projeto Fonte PMI 2013 p 161 Adaptado Já a estimativa de duração das atividades referese ao número de períodos de trabalho necessários para realizar determinada atividade com seus recursos previamente estimados Segundo o PMBOK PMI 2013 p 165 o grande benefício desse processo é fornecer a quantidade de tempo necessário para concluir cada atividade A Figura 5 apresenta esquematicamente as entradas e saídas desse processo Figura 5 Processo de estimar duração das atividades Entradas Estimativa de tempo Saídas 1 Plano de gerenciamento do crono grama 2 Lista de atividades 3 Atributos das atividades 4 Calendário dos recursos 5 Registro dos riscos 6 Especificação do escopo do projeto 7 Requisitos de recursos das atividades 8 Estrutura analítica dos recursos 9 Fatores ambientais da empresa 10 Ativos de processos organizacionais 1 Estimativa de dura ção das atividades 2 Atualização dos docu mentos do projeto Fonte PMI 2013 p 166 Adaptado 123 Gestão de tempo e recursos humanos É importante mencionarmos algumas técnicas de estimativas da duração das atividades tais como a estimativa análoga a estimativa paramétrica e a estimativa de três pontos Estimativa análoga como o próprio nome identifica referese à esti mativa de tempo ou custo de projeto que verifica os dados de históricos de projetos semelhantes para se balizar A estimativa paramétrica faz uso de um algoritmo para calcular o custo e duração O algoritmo utiliza dados de histó ricos e parâmetros de projeto Por último a estimativa de três pontos utiliza três perspectivas para definir uma faixa aproximada para a duração de uma atividade Conforme destaca o PMBOK 2013 p 169 2 perspectiva otimista baseada na análise do melhor cenário para a atividade 2 perspectiva pessimista baseada na análise do pior cenário para a atividade 2 perspectiva provável considera condições e cenários realistas de disponibilidade de recursos e produtividade para a execução da atividade De posse de todos os itens mencionados podemos agora desenvolver o cronograma do projeto 615 Desenvolver o cronograma do projeto Segundo o PMBOK PMI 2013 p 172 desenvolver o cronograma é o processo de análise de sequências das atividades suas durações recursos necessários e restrições do cronograma visando criar o modelo do crono grama do projeto Ainda segundo a mesma fonte O principal benefício deste processo é que a inserção das atividades do cronograma suas durações recursos disponibilidades de recur sos e relacionamentos lógicos na ferramenta de elaboração do crono grama gera um modelo de cronograma com datas planejadas para a conclusão das atividades do projeto PMI 2013 p 172 Gerência de projetos em TI 124 As entradas desse processo são as saídas de todos os processos anteriores 2 linha de base do cronograma 2 cronograma do projeto 2 dados do cronograma 2 calendário do projeto 2 atualizações do plano de gerenciamento do projeto 2 atualizações nos documentos do projeto As três figuras a seguir apresentam um exemplo do resultado desse pro cesso do cronograma A Figura 6 apresenta um exemplo do cronograma de marcos do projeto Figura 6 Marcos do cronograma do projeto Data dos dados Identificador da atividade Descrição da atividade Unidade de calendário Projetar a estrutura de tempo do cronograma Período 1 Período 2 Período 3 Período 4 Período 5 11 MB Iniciar novo produto z 0 111 M1 Completar componente 1 0 112 M1 Completar componente 2 0 113 M1 Completar integração dos componentes 1 e 2 0 113 EG Terminar novo produto z 0 Fonte PMI 2013 p 183 Já a Figura 7 apresenta um exemplo do resumo do cronograma Figura 7 Resumo do cronograma do projeto Identificador da atividade Descrição da atividade Unidade de calendário Projetar a estrutura de tempo do cronograma Período 1 Período 2 Período 3 Período 4 Período 5 11 Desenvolver e entregar novo produto z 120 111 Pacote de trabalho 1 componente 1 67 112 Pacote de trabalho 2 componente 2 53 113 Pacote de trabalho 3 componentes integra dos 1 e 2 53 Data dos dados Fonte PMI 2013 p 183 125 Gestão de tempo e recursos humanos E por fim a Figura 8 apresenta um exemplo do cronograma detalhado Figura 8 Cronograma detalhado do projeto Identificador de atividade Descrição da atividade Unidades de calendário Projetar a estrutura de tempo do cronograma Período 1 Período 2 Período 3 Período 4 Período 5 11 MB Iniciar novo produto Z 0 11 Desenvolver e entregar produto Z 120 111 Pacote de trabalho 1 Componente 1 67 111D Projetar componente 1 20 111B Construir componente 1 33 111T Testar componente 1 14 111M1 Completar componente 1 0 112 Pacote de trabalho 2 Componente 2 53 112D Projetar componente 2 14 112B Construir componente 2 28 112T Testar componente 2 11 112M1 Completar componente 2 0 113 Pacote de trabalho 3 Componentes integrados 1 e 2 53 113G Integrar componentes 1 e 2 como produto 2 14 113T Completar integração dos componentes 1 e 2 32 113M1 Testar componentes integrados como produto Z 0 113P Entregar produto Z 7 113EG Terminar novo produto Z 0 Cronograma detalhado TI II Data dos dados Fonte PMI 2013 p 183 616 Controlar o cronograma O PMBOK PMI 2013 p 185 destaca que o processo de con trolar o cronograma se refere ao monitoramento do andamento de cada atividade do projeto Tem como objetivo a atualização dos dados no decorrer do processo e o gerenciamento das mudanças feitas na linha de base do cronograma Gerência de projetos em TI 126 O principal benefício é ter sempre em vista a diferença tempos e custos entre o que foi planejado e o que está sendo realizado possibilitando assim a tomada de medidas corretivas e preventivas para minimizar o risco do projeto A Figura 9 apresenta esquematicamente as entradas e saídas desse processo Figura 9 Entradas e saídas do processo de controlar cronograma Entradas Controlar cronograma Saídas 1 Plano de gerenciamento do cronograma 2 Cronograma do projeto 3 Dados de desempenho do trabalho 4 Calendário do projeto 5 Dados do cronograma 6 Ativos de processos organizacionais 1 Informações sobre o desempe nho do trabalho 2 Previsões de cronograma 3 Solicitações de mudanças 4 Atualizações no plano de ge renciamento do projeto 5 Atualizações nos documentos do projeto 6 Atualizações nos ativos de processos organizacionais Fonte PMI 2013 p 185 Adaptado Vale a pena destacar que esse processo de controle do cronograma pode interferir no projeto como um todo dado que tem com uma de suas saídas as solicitações de mudanças e a atualização do plano de gerencia mento do projeto 62 Definindo as especialidades necessárias Como foi verificado na primeira parte deste capítulo cada uma das atividades previstas e sequenciadas do cronograma necessita de uma ou mais pessoas para sua realização Porém como se pode supor cada pessoa da equipe vinculada à execução de uma ou mais atividades do projeto deve dominar determinados conhecimentos e o domínio dessa habilidade ou conhecimento é o que destaca cada integrante da equipe dando a elea sua devida importância 127 Gestão de tempo e recursos humanos A responsabilidade sobre essas definições de contratações treinamentos alocação e realocação do recurso correto na atividade correta recai sobre a ges tão de recursos humanos Segundo o PMBOK PMI 2013 p 258 é de responsabilidade da gestão de recursos humanos o estabelecimento dos papéis responsabilidades e organogramas do projeto além do plano de gerenciamento de pessoal incluindo o cronograma para a mobilização e liberação de pessoal Os processos do gerenciamento dos recursos humanos do projeto estão relacionados no quadro a seguir Quadro 2 Lista de processos do gerenciamento dos recursos humanos do projeto Grupo de processos Processos de gerenciamento dos recursos humanos do projeto Iniciação vazio Planejamento Planejar o gerenciamento dos recursos humanos Execução Mobilizar a equipe do projeto Desenvolver a equipe do projeto Gerenciar a equipe do projeto Controle vazio Encerramento vazio Fonte PMI 2013 Adaptado Repare que diferentemente do que aconteceu com os processos do gerenciamento do escopo ou do tempo para o caso dos processos relaciona dos ao gerenciamento dos recursos humanos do projeto temos que a maioria deles deve ser executada na fase de execução do projeto e não mais na fase de planejamento e de controle Isso se justifica por um fator simples a equipe do projeto irá executar as atividades do projeto e portanto está vinculada à fase do projeto cor respondente para as ações de contratar desenvolver e gerenciar as equipes Gerência de projetos em TI 128 envolvidas A seguir estão detalhados cada um dos processos relacionados no Quadro 2 621 Planejar o gerenciamento dos recursos humanos do projeto Conforme destaca o PMBOK PMI 2013 p 438 o processo de geren ciamento dos recursos humanos do projeto tem a função de identificar e docu mentar os papéis responsabilidades e habilidades necessárias de cada compo nente da equipe do projeto para que ele seja executado de forma adequada e atinja seu objetivo definido no escopo no tempo e custo apropriado A Figura 10 apresenta esquematicamente as entradas e saídas desse processo Figura 10 Entradas e saídas do processo de planejar o gerenciamento dos recursos humanos3 Entradas Gerenciamento dos recursos humanos Saídas 1 Planejamento de gerenciamento do projeto 2 Requisitos de recursos das atividades 3 Fatores ambientais da empresa 4 Ativos de processos organizacionais 1 Plano de gerenciamento de recursos humanos Fonte PMI 2013 p 438 Adaptado 622 Mobilizar a equipe do projeto Esse processo tem a função de fazer o destacamento de cada membro da equipe do projeto necessário para aquele momento Conforme podemos supor a maioria dos integrantes das equipes do projeto não terão suas habili dades necessárias em todos os momentos do projeto Sendo assim a gestão de RH deve baseada no plano de gestão mobilizar cada integrante do projeto no momento da realização das atividades em que eles são necessários e libe randoos quando a atividade finaliza 3 Na seção Ampliando seus conhecimentos deste capítulo se encontra um exemplo do mo delo do plano de gerenciamento do RH do projeto 129 Gestão de tempo e recursos humanos A Figura 11 apresenta esquematicamente as entradas e saídas desse processo Figura 11 Entradas e saídas do processo de mobilizar a equipe do projeto Entradas Mobilizar a equipe do projeto Saídas 1 Plano de gerenciamento dos recursos humanos 2 Fatores ambientais da empresa 3 Ativos de processos organizacionais 1 Atribuição do pessoal no projeto 2 Calendários dos recursos 3 Atualizações no plano de geren ciamento do projeto Fonte PMI 2013 p 447 Adaptado É importante frisar que a correta administração e o controle dos recursos humanos destacados para cada atividade do projeto têm impacto direto no custo 623 Desenvolver a equipe do projeto Desenvolver a equipe do projeto não diz respeito apenas ao desenvol vimento de competências e habilidades técnicas mediante cursos e treina mentos mas também à realização de atividades de integração para melhorar o desempenho da equipe do projeto como um todo resultando num tra balho em equipe melhorado motivação dos empregados e redução de taxas de rotatividade A Figura 12 apresenta esquematicamente as entradas e saídas desse processo Figura 12 Entradas e saídas do processo de desenvolver a equipe do projeto Entradas Desenvolver a equipe do projeto Saídas 1 Plano de gerenciamento dos recursos humanos 2 Designações do pessoal do projeto 3 Calendário dos recursos 1 Avaliação do desempenho da equipe 2 Atualizações nos fatores am bientais da empresa Fonte PMI 2013 p 273 Adaptado Gerência de projetos em TI 130 624 Gerenciar a equipe do projeto Segundo o PMBOK o processo de gerenciamento da equipe do projeto pode ser definido como o processo de acompanhar o desempenho dos membros da equipe fornecer feedback resolver problemas e gerenciar mudanças para oti mizar o desempenho do projeto O principal benefício deste processo é que ele influencia o comportamento da equipe gerencia conflitos soluciona problemas e avalia o desempenho dos membros da equipe PMI 2013 p 448 A Figura 13 representa as entradas e saídas desse processo Figura 13 Entradas e saídas do processo de gerenciar a equipe do projeto Entradas Gerenciar a equipe do projeto Saídas 1 Plano de gerenciamento dos recursos humanos 2 Atribuições do pessoal no projeto 3 Avaliações do desempenho da equipe 4 Registro das questões 5 Relatórios de desempenho do tra balho 6 Ativos de processos organizacionais 1 Solicitações de mudanças 2 Atualizações no plano de geren ciamento do projeto 3 Atualizações nos fatores ambien tais da empresa 4 Atualizações nos ativos de proces sos organizacionais Fonte PMI 2013 p 448 Adaptado É importante notarmos que esse processo precisa da ação direta do ges tor do projeto de forma a selecionar os indivíduos mais adequados para integrar a equipe e uma vez selecionados manter a equipe coesa e seus integrantes motivados 63 Alguns conceitos e ferramentas Nesta terceira parte do capítulo trataremos de dois temas muito impor tantes para o correto entendimento da gestão do tempo do projeto e para a 131 Gestão de tempo e recursos humanos montagem do cronograma do projeto o diagrama de rede e o método do caminho crítico 631 Diagrama de rede Não é difícil percebermos que uma vez que as atividades necessárias para a realização do projeto foram identificadas surge a necessidade de orga nizálas e relacionálas em uma sequência lógica destacando seus prérequisi tos dependências caso existam eou précondições Nesse sentido uma ferramenta muito útil é o diagrama de rede do cro nograma do projeto uma representação gráfica das relações lógicas também chamadas de dependências entre as atividades do cronograma do projeto Existem vários métodos para se desenhar um diagrama de redes mas segundo Silva 2015 o mais utilizado é o método do diagrama de prece dência MDP Nesse método os nós representam as atividades e as setas representam as dependências entre elas Existem quatro tipos de dependências possíveis entre as atividades em um projeto dependência obrigatória dependência arbitrada dependência externa e dependência interna Já no que se refere aos relacionamentos entre as atividades o diagrama de redes apresenta quatro tipos de relacionamentos 2 Término para início TI a atividade predecessora deve ser finali zada antes do início da atividade sucessora 2 Início para início II a atividade predecessora deve ser iniciada quando a sucessora iniciar 2 Término para término TT a atividade predecessora deve ser finalizada quando a sucessora terminar 2 Início para término IT a atividade predecessora deve ser ini ciada antes que a sucessora finalize Gerência de projetos em TI 132 A Figura 14 apresenta esquematicamente o método do diagrama de pre cedência MDP com os quatro tipos de relacionamentos descritos Figura 14 Método do diagrama de precedência MDP e tipos de relações Atividade A Atividade B Atividade A Atividade A Atividade B Atividade B Atividade A Atividade B Término para início TI Início para início II Início para término IT Término para término IT Fonte PMI 2013 p 157 A Figura 15 apresenta um exemplo de diagrama de redes Figura 15 Diagrama de redes do cronograma do projeto Início Término B D E C G I F J L A K H II 10 II 15 TT II Fonte PMI 2013 p 160 133 Gestão de tempo e recursos humanos 632 Método do caminho crítico O método do caminho crítico segundo Martins 2012 referese a um conjunto de técnicas utilizadas para o planejamento e o controle de projetos mais especificamente para o controle dos tempos e dos custos do projeto Já para o PMBOK PMI 2013 p 176 esse é um método usado para estimar a duração mínima do projeto e determinar o grau de flexibilidade4 nos cami nhos lógicos da rede dentro do modelo do cronograma De fato temos duas técnicas para o cálculo do caminho crítico de um projeto o CPM Critical Path Method e o PERT Program Evaluation and Review Technique mas por serem muito semelhantes utilizaremos a ter minologia PERTCOM como se fosse apenas uma técnica Conforme destaca Martins 2012 a ideia básica do caminho crítico está na identificação do caminho sequência de atividades que consome mais tempo para a execução do projeto A Figura 16 a seguir representa o dia grama de redes de um projeto com as atividades identificadas por letras que estão sempre entre um conjunto de nós representando a situação inicial do projeto antes da execução da atividade e a situação final do projeto depois da execução da atividade em questão Figura 16 Diagrama de redes do projeto 1 2 3 4 5 C E B A F D Fonte Elaborada pelo autor 4 Em qualquer caminho de rede a flexibilidade do cronograma é medida pela quantidade de tempo que uma atividade pode atrasar ou ser estendida a partir da sua data de início sem atra sar a data de término do projeto ou violar uma restrição do cronograma PMI 2013 p 177 Gerência de projetos em TI 134 Podemos identificar claramente a presença de três caminhos na árvore de atividades desse projeto a saber 2 o primeiro caminho determinado pelos nós 1245 2 o segundo caminho determinado pelos nós 1345 2 o terceiro caminho determinado pelos nós 135 Temos também que o projeto inicia na situação ou status 1 e após a execução da atividade A passa para a situação ou status 2 e assim por diante Para determinar o caminho crítico do projeto precisamos conhecer o tempo gasto para executar cada atividade envolvida Desse modo utilizando ainda a Figura 16 temos que 2 para a realização da atividade A necessitamos de 3 unidades de tempo 2 para a realização da atividade B necessitamos de 7 unidades de tempo 2 para a realização da atividade C necessitamos de 5 unidades de tempo 2 para a realização da atividade D necessitamos de 2 unidades de tempo 2 para a realização da atividade E necessitamos de 4 unidades de tempo 2 para a realização da atividade F necessitamos de 3 unidades de tempo Isso posto temos que o primeiro caminho composto pelos nós 124 5 precisa de 9 unidades de tempo para ser concluído Já o segundo caminho composto pelos nós 1345 precisa de 13 unidades de tempo e finalmente o terceiro caminho composto pelos nós 135 precisa de 10 unidades de tempo para ser concluído Concluímos então que o caminho crítico para o exemplo apresentado na Figura 16 é o segundo composto pelos nós 1345 que necessita de 13 unidades de tempo para ser concluído Como consequência o primeiro caminho 1245 possui uma folga de 4 unidades de tempo e o terceiro caminho 135 possui folga de 3 unidades de tempo Vale lembrar que as folgas apresentadas nos caminhos não críticos permi tem ao gestor de projeto gerenciar qualquer atraso em decorrência de algum 135 Gestão de tempo e recursos humanos problema na infraestrutura nos recursos humanos ou mesmo na definição de algum objetivo Porém no caminho crítico em que temos folga zero nenhum erro pode acontecer No que se refere às folgas do processo Paiva 2011 destaca que é pos sível ter para cada atividade a folga livre e a folga total A primeira informa quanto tempo uma atividade pode atrasar sem que haja impacto no início da atividade sucessora e a segunda informa quanto tempo uma atividade pode atrasar sem que haja impacto para o término do projeto Ampliando seus conhecimentos O excerto a seguir apresenta o conceito de linha de base necessário para entender o desenvolvimento do cronograma Linhas de base RIBEIRO GARCIA 2017 Segundo Vargas 2012 uma linha de base nada mais é do que uma foto sobre os detalhes do projeto ou seja um retrato do contexto do projeto fornecendo um padrão que proporciona referência para alguma comparação Vargas 2012 diz ainda que um projeto sem linhas de base não é controlado Concluise que as linhas de base são os conjuntos de detalhamentos dos aspectos mapea dos em cada área de conhecimento planejados para aten dimento à forma de condução mais eficaz em prol do sucesso de um empreendimento Diante disso tornase imprescindível que durante a fase de planejamento várias linhas de base sejam gravadas À medida que as áreas de conhecimento são desenvolvidas no projeto Gerência de projetos em TI 136 temse como saídas linhas de base planejadas As linhas de base do projeto servem para medir a qualidade do plane jamento elaborado na forma de indicadores por exemplo Análise do Valor Agregado É uma boa prática que as linhas de base do projeto não sejam alteradas constantemente desde que a factibilidade de execu ção do plano original seja mantida Com isso não se perde a referência para comparações entre planejado versus execu tado o que irá facilitar a tomada de ações corretivas Apresentamos na sequência exemplos de modelos do plano de gerenciamento de tempo do projeto do plano de gerenciamento de RH e da matriz de responsabilidade do projeto com base em Trentim 2012 Modelos de documentos Baseado em TRENTIM 2012 Documento 1 plano de gerenciamento de tempo Título do Projeto Data de Início Número Gerente Patrocinador Cliente 1 Plano de gerenciamento de tempo Descrever como serão feitas as estimativas de recursos e de tempo das atividades para chegar ao cronograma opinião de especialistas informações históricas etc Descrever como será controlado o cronograma quais atividades poderão ser adian tadas ou atrasadas restrições de tempo gerenciamento do caminho crítico etc 137 Gestão de tempo e recursos humanos 2 Definição de atividades estimativa de recursos e durações Lista de atividades e tarefas para concluir cada item da EAP Estrutura Analítica do Projeto A lista de atividades deve ser consolidada em uma planilha conforme a Matriz de Responsabilidades 3 Sequenciamento das atividades diagrama de rede Descrever a sequência lógica das atividades para criar o diagrama de rede e des cobrir o caminho crítico Deve ter forma gráfica para facilitar a visualização 4 Cronograma Colocar o cronograma planilha ou MSProject Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data Assinatura do cliente Data Fonte Elaborado pelo autor Documento 2 Plano de gerenciamento de recursos humanos Título do Projeto Data de Início Número Gerente Patrocinador Cliente Gerência de projetos em TI 138 1 Aspectos gerais Descrever a justificativa da necessidade de contratação de profissionais CLT PJ Temporários etc 2 Tabela de recursos humanos Descrever a quantidade de profissionais e as qualificações exigidas Incluir tempo estimado de utilização de cada profissional com data de mobilização e de liberação estimadas Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data Assinatura do cliente Data Fonte Elaborado pelo autor Documento 3 Matriz de responsabilidades do projeto Título do projeto Número Gerente Patrocinador AGENTE 139 Gestão de tempo e recursos humanos ATIVIDADE 1 2 3 4 T V C A I Legenda T Toma decisão 1 Patrocinador V Valida 2 Gerente do projeto C É consultado 3 Gerente funcional da área envolvida A Analisa 4 Cliente I É informado Fonte Elaborado pelo autor Atividades 1 Explique cada um dos quatro tipos de dependência entre atividades em um projeto 2 Cite exemplos explicativos dos quatro tipos de relacionamentos en tre atividades 3 Explique a figura a seguir demonstrando os caminhos possíveis as unidades de tempo totais de cada um e apontando qual é o cami nho crítico Gerência de projetos em TI 140 Figura Diagrama de rede do projeto método do caminho crítico 6 5 10 B 11 5 15 6 10 15 C 6 0 15 16 15 30 D 16 0 30 Início Caminho A B D 25 Caminho A C D 30 Caminho crítico Fim Início mais cedo Duração Término mais cedo Nome da atividade Início mais tarde Folga total Término mais tarde CHAVE Atividade no nó Elo de caminho crítico Elo de caminho não crítico 1 5 3 A 1 0 5 Fonte PMI 2013 p 177 4 Explique o que é linha de base do projeto Gestão de recursos materiais e humanos Na primeira parte deste capítulo trataremos sobre a gestão da aquisição de materiais equipamentos ou dispositivos necessários para a realização adequada das atividades previstas no cronograma do projeto Na segunda e terceira partes trataremos sobre o risco do projeto destacando o erro humano como um risco que não pode passar despercebido pelo gestor Mostraremos os tipos de riscos exis tentes e quais são suas características bem como algumas ferramen tas gráficas para auxiliar na identificação e na análise quantitativa dos riscos do projeto Ao finalizar a leitura deste capítulo você terá uma boa visão da importância de se controlar as aquisições do pro jeto e principalmente os riscos que podem impactálo 7 Gerência de projetos em TI 142 71 Determinar os materiais necessários para o projeto Conforme verificado no capítulo anterior para se ter uma previsão rea lista do tempo necessário para se executar uma atividade do projeto é neces sário identificar a tarefa em questão a equipe de recursos humanos que será responsável por executála e os recursos materiais ou aquisições que serão disponibilizados para sua execução Podemos ver claramente isso no exemplo da contratação de um lenhador para derrubar árvores de um determinado terreno Quanto tempo o lenhador vai demorar para derrubar as árvores Isso não depende apenas da experiência dele em derrubar árvores Depende também de que tipo de ferramenta estará disponível para ele Outro item importante é entender que não adianta nada disponibilizar a melhor e mais avançada ferramenta tecnológica para quem não sabe utilizála A área do conhecimento da gestão de projetos responsável por verificar e gerenciar quais as demandas de materiais necessários para execução das atividades é a gestão de recursos materiais ou gerenciamento das aquisições do projeto Segundo o PMBOK PMI 2013 p 355 o gerenciamento das aqui sições do projeto inclui os processos necessários para comprar ou adquirir produtos serviços ou resultados externos à equipe do projeto O Quadro 1 apresenta uma visão geral sobre os processos dessa área do conhecimento de projeto Quadro 1 Lista de processos do gerenciamento de aquisições do projeto Grupo de processos Processos de gerenciamento de aquisições projeto Iniciação vazio Planejamento Planejar o gerenciamento de aquisições Execução Conduzir as aquisições Controle Controlar as aquisições Encerramento Encerrar as aquisições Fonte PMI 2013 Adaptado 143 Gestão de recursos materiais e humanos Repare que para gerenciar as aquisições do projeto é necessário primeiro planejar como se dará o gerenciamento destas e isso acontece em todas as áreas do conhecimento Em seguida são realizados os processos de condução controle e por fim o encerramento das aquisições quando os materiais são liberados para utilização em outros processos Passamos a seguir a detalhar esses processos iniciando pelo planeja mento das aquisições 711 Planejar o gerenciamento das aquisições Esse é o processo de documentação das decisões de compras do projeto especificando a abordagem e identificando fornecedores em potencial PMI 2013 p 442 A Figura 1 apresenta as entradas e saídas desse processo Figura 1 Processo de planejar o gerenciamento das aquisições do projeto Entradas Planejar o gerenciamento das aquisições Saídas 1 Plano de gerenciamento do projeto 2 Plano de gerenciamento dos requi sitos 3 Registro dos riscos 4 Requisitos de recursos das atividades 5 Cronograma do projeto 6 Estimativa do custo das atividades 7 Registro das partes interessadas 8 Fatores ambientais da empresa 9 Ativos de processos organizacionais 1 Plano de gerenciamento das aquisições 2 Especificação do trabalho de aquisições 3 Documentos de aquisição 4 Critérios para a seleção de fontes 5 Decisão de fazer ou comprar 6 Solicitação de mudança 7 Atualização dos documentos do projeto Fonte PMI 2013 p 443 Adaptado É importante destacar que são necessários alguns documentos para que o planejamento do gerenciamento das aquisições seja realizado tais como a lista de requisitos de recursos das atividades o cronograma e a estimativa de custo do projeto Essa verificação identificada na Figura 1 confirma o que vimos nos capítulos anteriores pois para se fazer o geren ciamento das aquisições é necessário saber quais são as atividades e sua Gerência de projetos em TI 144 sequência conteúdos do cronograma quem são as equipes destinadas para cada atividade qual a habilidade que cada equipe deve ter e por fim qual material precisa ser adquirido para que a equipe realize a atividade conforme o tempo e custo previstos Seguese então o segundo processo do gerenciamento das aquisições do projeto que é feito na fase de execução do projeto 712 Conduzir as aquisições Nesse momento do projeto são escolhidos os fornecedores dos materiais a serem adquiridos e assinados os contratos de compra ou locação Segundo o PMBOK PMI 2013 p 449 esse é o processo de obtenção de respostas de fornecedores seleção de um fornecedor e adjudicação1 de um contrato Ainda segundo a mesma fonte serve para alinhar as expectativas internas e externas das partes interessadas por acordos estabelecidos Seus processos estão relacionados na Figura 2 Figura 2 Processo de condução das aquisições Entradas Condução das aquisições Saídas 1 Plano de gerenciamento das aquisições 2 Documentos de aquisição 3 Critérios para a seleção de fontes 4 Propostas de fornecedores 5 Documentos do projeto 6 Decisão de fazer ou comprar 7 Especificação do trabalho de aquisições 8 Ativos de processos organizacionais 1 Fornecedores selecionados 2 Acordos 3 Calendários do recurso 4 Solicitação de mudanças 5 Atualização do plano de gerenciamento do projeto 6 Atualização dos documen tos do projeto Fonte PMI 2013 p 449 Adaptado É importante verificar que conforme apresentado na Figura 2 para que a condução das aquisições seja realizada são necessários os documentos que definem o plano de gerenciamento das aquisições o critério de seleção das 1 Segundo o dicionário Michaelis adjudicar é conferir algo a alguém conceder entregar submeter MICHAELIS 2017 145 Gestão de recursos materiais e humanos fontes e as propostas dos fornecedores Depois da análise do gestor baseado na decisão de fazer ou comprar cujo modelo pode ser verificado no texto extra deste capítulo e nos documentos do projeto os fornecedores são sele cionados firmando acordos baseados no calendário dos recursos e na soli citação de mudanças Passamos agora para o terceiro processo na gestão de aquisições do projeto o que controla essas aquisições 713 Controlar as aquisições Depois de ter os fornecedores selecionados e os contratos firmados faz se necessário o controle desses contratos pois tudo deve estar bem alinhado ao cronograma do projeto Não é desejável mas é possível que determinado equipamento não possa ser entregue na data prevista por causa de algum imprevisto interno ou externo ao projeto O gestor precisa então ficar atento a qualquer mudança que possa acarretar atraso no cronograma ou alteração de custo dos materiais O processo de controlar aquisições permite o gerenciamento das relações de aquisição monitoramento do desempenho do contrato e de realizações de possíveis mudanças ou correções conforme necessário PMI 2013 p 458 A Figura 3 mostra o processo de controle de aquisições Figura 3 Processo de controlar aquisições Entradas Controle das aquisições Saídas 1 Plano de gerenciamento do projeto 2 Documentos de aquisição 3 Acordos 4 Solicitação de mudanças aprovadas 5 Relatório de desempenho do trabalho 6 Dados de desempenho do trabalho 1 Informação sobre o de sempenho do trabalho 2 Solicitações de mudança 3 Gerenciamento do projeto 4 Atualizações nos documentos do projeto 5 Atualizações nos ativos de processos organizacionais Fonte PMI 2013 p 458 Adaptado Gerência de projetos em TI 146 É importante notar na Figura 3 que uma das saídas do processo de controle de aquisições é o relatório de informações sobre o desempenho do trabalho o qual vai informar ao gestor como está sendo a execução das ativi dades em que cada recurso material foi disponibilizado Dessa forma o gestor pode agir pontualmente de maneira a corrigir quaisquer problemas e evitar danos ao tempo ou custo do projeto Repare também que existe um documento de saída chamado solicitação de mudança Esse documento deve ser utilizado para o caso de haver qualquer problema no desenvolvimento das atividades conforme o relatório de infor mações sobre o desempenho do trabalho e que não possa ser corrigido em tempo pelo gestor Segundo Montes 2016 a única coisa que é constante nos projetos são as mudanças Então a questão não é se preocupar quando ou se algo no projeto mudou mas sim ficar atento a qualquer modificação que possa causar impacto a ele e mais do que isso uma vez identificado o impacto negativo tomar as providências para reduzir as perdas causadas por este Seguimos agora para o processo de encerramento das aquisições 714 Encerrar as aquisições Naturalmente as ferramentas os materiais e dispositivos contratados comprados eou locados para a execução de uma atividade do projeto podem ser liberados logo que a referida atividade é finalizada Sendo assim fazse necessário encerrar as aquisições isso é devolver os materiais locados a seus devidos fornecedores e realizar uma avaliação da produtividade desse material para que esse conhecimento possa ser utilizado posteriormente É importante mencionar que uma aquisição pode ser encerrada no tér mino de determinada atividade ou pode ser encerrada devido à interrupção cancelamento de uma atividade do cronograma Esse é o processo que finaliza todas as aquisições do projeto e que segundo PMBOK PMI 2013 p 461 deve documentar todos os acordos realizados todas as alterações solicitadas todos os desempenhos dos materiais adquiridos ou locados no decorrer do projeto A Figura 4 apresenta as entradas e saídas do processo de encerra mento de aquisições 147 Gestão de recursos materiais e humanos Figura 4 Processo de encerrar aquisições Entradas Encerramento das aquisições Saídas 1 Plano de gerenciamento do projeto 2 Documentos de aquisição 1 Aquisições encerradas 2 Atualizações dos ativos de processos organizacionais Fonte PMI 2013 p 461 Com o encerramento das aquisições fechamos a primeira parte deste capítulo Passamos agora para a segunda parte que trata do gerenciamento dos riscos do projeto 72 Os riscos do projeto É de conhecimento geral que toda atividade humana toda e qualquer empreitada está sujeita a sofrer ações internas ou externas previsíveis ou não e isso também ocorre no caso dos projetos impactando seus resultados Se existe a possibilidade de que algo dê errado durante o processo isso consti tui um risco para seu bom desempenho Naturalmente quanto maior for a probabilidade de que algo aconteça maior o risco Esta segunda parte do capítulo trata justamente de apresentar como a metodologia definida e utili zada pelo PMI Project Management Institute Instituto de Gerenciamento de Projetos fornece condições para a identificação a avaliação e o controle de riscos inerentes aos projetos Segundo Ruppenthal 2013 p 26 a palavra risco é uma derivação do antigo termo italiano riscare que representa a evolução social ou ato de ousar que possibilita uma escolha do homem e não um destino divina mente determinado Nesse sentido o risco representa sempre algo incerto gerado por uma atitude deliberada do homem e portanto pode causar tanto resultados positivos quanto eventos indesejáveis Sendo assim ele precisa ser gerenciado Gerência de projetos em TI 148 O Quadro 2 apresenta os processos do gerenciamento dos riscos do pro jeto que serão discutidos nesta parte do capítulo Quadro 2 Lista de processos do gerenciamento dos riscos do projeto Grupo de processos Processos de gerenciamento dos riscos do projeto Iniciação vazio Planejamento Planejar o gerenciamento dos riscos do projeto Identificar os riscos Realizar a análise quantitativa dos riscos Realizar a análise qualitativa dos riscos Planejar as respostas aos riscos Execução vazio Controle Controlar os riscos do projeto Encerramento vazio Fonte PMI 2013 Adaptado 721 Planejar o gerenciamento dos riscos do projeto Esse é o processo encarregado de definir como conduzir as atividades de gerenciamento dos riscos de um projeto Segundo o PMBOK PMI 2013 p 439 esse processo garante que o grau o tipo e a visibilidade dos riscos sejam proporcionais à importância do projeto As entradas e saídas do planejamento do gerenciamento dos riscos do projeto são apresentadas na figura a seguir Figura 5 Processo de planejar o gerenciamento dos riscos Entradas Planejamento do gerenciamento dos riscos Saídas 1 Plano de gerenciamento do projeto 2 Termo de abertura do projeto 3 Registros das partes interessadas 4 Fatores ambientais da empresa 5 Ativos de processos organizacionais 1 Plano de gerenciamento de riscos Fonte PMI 2013 p 439 149 Gestão de recursos materiais e humanos É importante para o gestor ao planejar o gerenciamento dos riscos do projeto entender que existem tipos ou naturezas diferentes de riscos que segundo Ruppenthal 2013 p 29 têm características diferentes em fun ção do ambiente de atuação da empresa e de suas próprias características operacionais Os riscos podem ser classificados como puros ou estáticos e especulati vos ou dinâmicos conforme apresentado na Figura 6 Figura 6 Classificação dos riscos Riscos puros especulativos à propriedade administrativos de mercado às pessoas políticos financeiros de personalidade de inovação de produção Fonte RUPPENTHAL 2013 p 29 Ainda segundo a mesma autora se um risco puro se materializa e não é evitado ou mitigado normalmente resultará em perdas Como exemplo podemos destacar que os riscos à propriedade consideram perdas relativas a incêndios roubos terremotos etc Já os riscos relativos às pessoas consideram doenças ocupacionais e acidentes de trabalho e por fim os riscos relativos a responsabilidades referemse por exemplo às perdas causadas por eventuais pagamentos de indenizações Por sua vez os riscos do tipo especulativo não são concretos como o tipo puro Riscos administrativos são decorrentes de erros nas tomadas de decisões da empresa que podem afetar o bom andamento do projeto e riscos Gerência de projetos em TI 150 de mercado são relativos às incertezas do ambiente em que a empresa atua A aceitação ou rejeição do produto serviço ou resultado numa consulta de um prélançamento que está sendo desenvolvido pode impactar o projeto positiva ou negativamente E por fim os riscos financeiros podem impactar o projeto da mesma forma A flutuação do dólar ou da bolsa de valores pode também impactar o projeto positiva ou negativamente dependendo do pro duto serviço ou resultado que está sendo desenvolvido No que diz respeito às saídas apresentadas na Figura 5 o documento de plano de gerenciamento de risco segundo o PMBOK 2013 p 316318 descreve como as atividades de gerenciamento de risco deverão ser estrutu radas e executadas e inclui entre seus itens outra maneira de agrupar os ris cos baseada em suas causas Essa categorização de riscos é uma representação hierárquica denominada de estrutura analítica dos riscos EAR A Figura 7 apresenta um exemplo de EAR Figura 7 Exemplo de EAR Projetos 21 Subcontratadas e fornecedores 22 Regulador 23 Mercado 24 Cliente 1 Técnico 2 Externo 3 Organizacional 4 Gerenciamento de projetos 25 Condições climáticas 11 Requisitos 12 Tecnologia 13 Complexidade e interfaces 14 Desempenhos e confiabilidade 15 Qualidade 31 Dependências do projeto 32 Recursos 33 Financiamento 34 Priorização 41 Estimativas 42 Planejamento 43 Controle 44 Comunicação Fonte PMI 2013 p 317 151 Gestão de recursos materiais e humanos Outros itens que devem ser considerados no plano de gerenciamento de risco são a definição de probabilidade e impacto dos riscos e a matriz de probabilidade e impacto descritas a seguir 2 Definição de probabilidade e impacto dos riscos A análise de riscos de um projeto precisa distinguir probabilidades e impactos diferentes para cada conjunto de riscos identificado pois a proba bilidade de ocorrência de um risco varia de acordo com o projeto assim como o impacto desse risco também varia O Quadro 3 apre senta um exemplo de definição de escala de impacto de risco para quatro objetivos do projeto Quadro 3 Definição de escala de impacto de risco2 Condições definidas para as escalas de impacto de um risco nos objetivos principais do projeto Exemplos são mostrados somente para impactos negativos Objetivo do projeto Escalas relativas ou numéricas são mostradas Muito baixo005 Baixo010 Moderado020 Alto040 Muito alto080 Custo Aumento insignificante do custo 10 aumento do custo 10 20 aumento do custo 20 40 aumento do custo 40 aumento do custo Tempo Aumento insignificante do tempo 5 aumento do tempo 5 10 aumento do tempo 10 20 aumento do tempo 20 aumento do tempo Escopo Diminuição pouco notável do escopo Áreas secundárias do escopo afetadas Áreas princi pais do escopo afetadas Redução do escopo inaceitável para o patrocinador Produto final do projeto é efetiva mente inútil Qualidade Degradação pouco notável da qualidade Somente apli cações muito exigentes são afetadas Redução da qualidade requer aprovação do patrocinador Redução do escopo inacei tável para o patrocinador Produto final do projeto é efetiva mente inútil Fonte PMI 2013 p 318 2 Apresenta exemplos de definições dos riscos para quatro objetivos diferentes do projeto Eles devem ser ajustados no processo de planejar o gerenciamento dos riscos para o projeto em questão e para os limites de tolerância a riscos da organização As definições de impacto podem ser desenvol vidas para as oportunidades de uma maneira similar Gerência de projetos em TI 152 2 Matriz de probabilidade e impacto Conforme o PMBOK 2013 p 318 essa matriz é uma rede para o mapeamento de pro babilidade de ocorrência de cada risco e o seu impacto nos objeti vos do projeto caso ocorra É importante ressaltar que os riscos são priorizados conforme suas prováveis implicações no projeto e as combinações de probabilidade e impacto é que fazem determinado risco ser classificado como de alta moderada ou baixa importân cia A Tabela 1 apresenta um exemplo de uma escala numérica de impacto que pode ser aplicada a um determinado objetivo do pro jeto como por exemplo o custo o tempo o escopo ou a qualidade Tabela 1 Matriz de probabilidade e impacto Probabilidade Ameaças Oportunidades 090 005 009 018 036 072 072 036 018 009 005 070 004 007 014 028 056 056 028 014 007 004 050 003 005 010 020 040 040 020 010 005 003 030 002 003 006 012 024 024 012 006 003 002 010 001 001 002 004 008 008 004 002 001 001 005 Muito baixo 010 Baixo 020 Mode rado 040 Alto 080 Muito alto 080 Muito alto 040 Alto 020 Mode rado 010 Baixo 005 Muito baixo Fonte PMI 2013 p 331 Conforme podemos notar o conhecimento da tipologia da classifica ção e das probabilidades de um risco acontecer influencia diretamente no planejamento do gerenciamento dos riscos do projeto e deve ser considerado também no próximo item deste capítulo a identificação dos riscos 153 Gestão de recursos materiais e humanos 722 Identificar os riscos É o processo de determinação dos riscos que podem afetar o projeto bem como da documentação de suas características Segundo o PMBOK PMI 2013 p 440 o principal benefício desse processo é a documentação dos riscos existentes e o conhecimento e a capacidade que ele fornece à equipe no sentido de se antecipar aos problemas A Figura 8 apresenta as entradas e saídas desse processo Figura 8 Processo de identificação de riscos Entradas Identificação dos riscos Saídas 1 Plano de gerenciamento a dos riscos b dos custos c do cronograma d da qualidade e dos recursos humanos 2 Linha de base do escopo 3 Estimativas de a custos das atividades b duração das atividades 4 Registros das partes interessadas 5 Documentos do projeto 6 Documentos de aquisição 7 Fatores ambientais da empresa 8 Ativos e processos organizacionais 1 Registro do riscos Fonte PMI 2013 p 440 Adaptado O erro é inerente ao ser humano podendo acontecer quando menos se espera pois o comportamento humano nem sempre é coerente e racio nal Portanto o erro humano constitui um risco para qualquer atividade e não deve passar despercebido pelo gestor do projeto Sendo assim podemos entender que identificar os riscos e documentálos a fim de que a equipe fique bem munida de recursos para poder agir quando necessário deve con templar em certa medida a identificação dos erros humanos que possam ocorrer em uma atividade com o intuito de mitigálos Gerência de projetos em TI 154 Segundo relatado por Ruppenthal 2013 p 20 o erro humano é um desvio anormal em relação a uma norma ou padrão estabelecido e pode influenciar sobremaneira a confiabilidade de um projeto Com base no hexágono de causas do erro humano disponibilizado por Ruppenthal 2013 p 20 listamos as suas seis maiores causas 1 falta de atenção 2 condições ergonômicas inadequadas 3 falta de aptidão física ou mental 4 falta de capacidade 5 falta de informação 6 falta de motivação Com isso fica claro que além de olhar para o mundo exterior e interior ao projeto à procura de possíveis riscos o gestor deve atentarse para as con dições de cada integrante da equipe 723 Realizar a análise qualitativa dos riscos Depois de planejar como identificar os riscos e reagir a eles fazse neces sário priorizálos Priorizar riscos nesse contexto quer dizer identificar qual o risco que tem maior probabilidade de ocorrer e qual a possibilidade de o risco parar o projeto caso ele ocorra Segundo o PMBOK 2013 p 328 a análise qualitativa é um processo de priorização de riscos para posterior análise ou ação conforme o resultado indi cado pela combinação de sua probabilidade de ocorrência e impacto no projeto A Figura 9 apresenta as entradas e saídas do processo em questão Figura 9 Processo de análise qualitativa dos riscos Entradas Análise quantitativa dos riscos Saídas 1 Plano de gerenciamento de riscos 2 Linha de base de escopo 3 Registros de riscos 4 Fatores ambientais da empresa 5 Ativos de processos organizacionais 1 Atualização nos documentos do projeto Fonte PMI 2013 p 441 Adaptado 155 Gestão de recursos materiais e humanos Nessa figura podemos notar que a análise qualitativa dos riscos se dá com base na linha de base do escopo do projeto e é claro na lista dos riscos documento denominado registro dos riscos que obtivermos como saída do processo de identificação dos riscos 724 Realizar a análise quantitativa dos riscos O PMBOK PMI 2013 p 440 define a análise quantitativa dos riscos como o processo de se analisar numericamente o efeito dos riscos identifica dos nos objetivos custo prazo escopo qualidade etc do projeto A Figura 10 apresenta as entradas e saídas do processo em questão Figura 10 Análise quantitativa dos riscos Entradas Análise quantitativa dos riscos Saídas 1 Plano de gerenciamento de riscos 2 Linha de base do escopo 3 Plano de gerenciamento do cronograma 4 Registro dos riscos 5 Fatores ambientais da empresa 6 Ativos de processos organizacionais 1 Atualização nos documentos do projeto Fonte PMI 2013 p 441 Adaptado Em se tratando de ferramentas para auxiliar a realização da análise quan titativa dos riscos temos o diagrama tornado e o diagrama de árvore de deci sões o diagrama de causa raiz a análise Swot e a lista de verificação que serão abordados mais adiante 725 Planejar as respostas aos riscos Planejar respostas para os problemas que podem surgir é uma estratégia muito boa não só para gerentes de projetos mas para qualquer um que esteja envolvido num projeto pois nos sentimos muito mais seguros quando já sabemos como devemos agir se algo de errado acontecer e impactar o resul tado de nosso projeto Segundo o PMBOK PMI 2013 p 342 esse é o processo de desenvolvimento de opções para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto Gerência de projetos em TI 156 Vamos imaginar por exemplo que exista o risco de o pneu do seu carro furar enquanto você está viajando de férias Qual a diferença para a tran quilidade de todos os passageiros e até do condutor do veículo se todos souberem o que deve ser feito quando o pneu furar De maneira oposta qual será a tensão dos viajantes ao saber que o pneu não pode furar em momento algum pois se isso acontecer ninguém saberá o que fazer a respeito Nesse contexto assim com em muitos outros planejar as respostas aos riscos trará segurança a todos As entradas e saídas desse processo estão relacionadas na Figura 11 Figura 11 Processo de planejar as respostas aos riscos Entradas Planejar as respos tas aos riscos Saídas 1 Plano de gerenciamento de riscos 2 Regisros dos riscos 1 Atualizações no plano de gerenciamento do projeto 2 Atualizações nos docu mentos do projeto Fonte PMI 2013 p 342 Entre as ferramentas utilizadas para planejar as respostas aos riscos está o conjunto de quatro estratégias utilizadas em casos de riscos negativos e amea ças conforme destaca o PMBOK 2013 p 344 2 Prevenir A equipe do projeto toma providências para eliminar a probabilidade de ocorrência do risco identificado ou blindar o projeto contra o impacto decorrente desse risco 2 Transferir Nesse caso a equipe do projeto contrata outra equipe que ficará responsável por desenvolver respostas ao risco identifi cado ou tratar os danos causados por sua ocorrência 2 Mitigar Nesse caso a equipe do projeto trabalha para minimizar a probabilidade de ocorrência do risco ou dos danos causados pelo seu impacto no projeto 2 Aceitar Nesse caso a equipe do projeto apenas registra a exis tência do risco e classifica seu impacto mas não toma nenhuma 157 Gestão de recursos materiais e humanos atitude para evitálo Isso acontece quando não é economicamente viável tratar o risco identificado ou os impactos decorrentes dele 726 Controlar os riscos do projeto Segundo o PMBOK PMI 2013 p 349 o processo de controlar os riscos do projeto pode ser definido como O processo de implementação de respostas aos riscos acompanhamento dos riscos identificados monitora mento dos riscos residuais identificação de novos riscos e avaliação da eficácia da abordagem dos riscos no decorrer de todo o ciclo de vida do projeto As entradas e saídas desse processo estão apresentadas na Figura 12 Figura 12 Processo de controlar os riscos Entradas Controlar os riscos Saídas 1 Plano de gerenciamento do projeto 2 Registro dos riscos 3 Dados de desempenho do trabalho 4 Relatório de desempenho do trabalho 1 Informações sobre o desempenho do trabalho 2 Solicitações de mudança 3 Atualizações do plano de gerenciamento do projeto 4 Atualizações nos docu mentos do projeto 5 Atualizações nos ativos dos processos organizacionais Fonte PMI 2013 p 349 Adaptado 73 Outros procedimentos para análise de riscos do projeto 731 Diagrama tornado O diagrama tornado é uma ferramenta técnica gráfica que se enquadra na análise de sensibilidade do projeto e segundo Silva e Belderrain 2004 p 8 é utilizado para Gerência de projetos em TI 158 2 tomar melhores decisões 2 decidir quais dados estimados devem ser refinados ao tomar uma decisão 2 concentrarse nos elementos críticos durante a implementação Esse diagrama é utilizado conforme afirma o PMBOK PMI 2013 p 338 para comparar o grau de incerteza e o impacto das variáveis que tem um alto grau de incerteza com aquelas mais estáveis e pode ser montado em um plano x e y O eixo y deve conter cada tipo de risco ou incerteza de risco e no eixo x devem estar graduadas as incertezas e o impacto de cada risco É importante notar que o impacto para cada risco pode ser positivo ou negativo para o projeto A Figura 13 é um exemplo do diagrama tornado Figura 13 Diagrama tornado Risco 4 Risco 3 Risco 2 Risco 1 Impacto positivo Impacto negativo Fonte PMI 2013 Adaptado 732 Árvore de decisões Outro diagrama utilizado para auxiliar esse processo é o diagrama de árvore de decisões A Figura 14 representa um exemplo de uma árvore de decisões 159 Gestão de recursos materiais e humanos Figura 14 Diagrama de árvore de decisões PCa 05 PCaCa 05 PCoCa 05 PCaCo 05 PCoCo 05 PCo 05 A B D E F C G Cara Cara Coroa Coroa Coroa Fonte Wikimedia Commons Note na Figura 14 que cada nó representa um status ou situação Temos então que em um primeiro momento a moeda está no status ou situação inicial determinado pelo nó A Quando essa moeda for lançada terá probabilidade de resultar em cara que é representada pelo PCa e tem como valor 50 Da mesma forma a probabilidade de dar coroa representada por PCo é de 50 Uma vez que a moeda deu cara ela passa para o status determinado pelo nó B mas se for coroa passa para o status determinado pelo nó C Para um segundo lance da moeda ela poderá passar para o resultado determinado pelos pontos D e E caso saia do status determinado pelo nó B e pode passar para o resultado marcado pelos nós F ou G caso saia do nó C Gerência de projetos em TI 160 O status será D se e somente se o primeiro lance da moeda der cara e o segundo também A probabilidade de dar cara no segundo lance tendo como primeiro lance o resultado cara é representado por PCaCa que é de 50 O status será E se e somente se o resultado do segundo lance for coroa mas tiver como resultado do primeiro lance o resultado cara e é representado por PCoCa Da mesma forma acontece com os status representados pelos nós F e G partindo da ideia de que o primeiro lance deu coroa 733 Análise de causa raiz Segundo Aguiar 2014 p 39 a análise de causa raiz consiste na investigação do problema e identificação de suas causas para posterior tomada de ações corretivas Em outras palavras é um processo que tem como objetivo descobrir o que ocorreu identificar o motivo que levou a determinada ocorrência e determinar o que pode ser feito para prevenir a recorrência do problema Apesar de poder ser utilizado em todas as áreas e em todas as situações problema esse método demanda tempo e recursos para testar hipóteses dos quais muitas vezes as empresas não dispõem Assim uma boa prática é rela cionar os processos que podem ser submetidos a essa análise realizando uma priorização dos problemas que serão analisados O método de causa raiz consiste de cinco passos WEISS 2011 apud AGUIAR 2014 1 Iniciar a análise com a afirmação da situação que se deseja entender e resolver 2 Perguntar por que a afirmação anterior o problema ocorrido é verdadeira 3 Para a razão descrita que explica por que a afirmação anterior é verdadeira perguntar novamente 4 Continuar perguntando até que todos os porquês tenham sido levantados 5 Quando não houver mais porquês isso quer dizer que a raiz do problema foi identificada 161 Gestão de recursos materiais e humanos Segue um exemplo da utilização desse método 1 Por que os computadores desligaram Resposta Porque houve sobrecarga de energia 2 Por que houve uma sobrecarga Resposta Porque a rede ficou instável 3 Por que a rede ficou instável Resposta Porque houve grande utilização no mesmo período de tempo 4 Por que houve excesso de utilização da rede num mesmo período Resposta Porque foram contratados mais funcionários e compra dos mais equipamentos e não houve revisão da rede Note que nessa abordagem a sequência de perguntas e respostas dire ciona e explora o problema desde sua origem No que tange ao gerenciamento de riscos do projeto fica evidente que uma análise pode auxiliar a identificar a causa raiz dos riscos prioritários de cada processo Vale ressaltar que nem todos os riscos e erros são de aná lise tão simples e imediata quanto apresentado no exemplo Muitos deles requerem testes de hipóteses e demandam tempo e recursos materiais para serem executados 734 Análise Swot A análise Swot é uma técnica para identificação de forças fraquezas oportunidades e ameaças sendo as duas primeiras relativas aos fatores inter nos da empresa departamento ou processo em questão e as duas últimas relativas aos fatores externos A Figura 15 apresenta esquematicamente essa técnica que a princí pio não foi desenvolvida para a identificação de riscos mas conforme as definições modernas de risco que podem ser tanto positivos quanto negati vos isto é um projeto pode correr o risco de algo bom ou ruim acontecer temos que as oportunidades fator externo e as forças fatores internos do Gerência de projetos em TI 162 projeto podem ser consideradas como riscos positivos Já as ameaças fato res externos e as fraquezas fatores internos podem ser consideradas como riscos negativos Indo um pouco mais a fundo nessa análise podemos considerar as ameaças fatores externos como riscos negativos e as fraquezas fatores inter nos negativos como um agravante do risco externo Da mesma forma temos que as oportunidades fatores externos podem ser consideradas riscos posi tivos e as forças fatores internos positivos como elementos que mitigam as fraquezas ou ameaças Figura 15 Diagrama Swot Internas Forças Fraquezas Ameaças Oportunidades Internas Externas Externas Fonte Elaborada pelo autor 735 Lista de verificação A lista de verificação de riscos ou checklist corporativo é uma ferramenta de identificação de riscos composta por uma lista dos riscos ocorridos ou já identificados em outros projetos Essa ferramenta possui três colunas causas potenciais descrição do risco e impactos potenciais Segundo o PMI 2013 a mais frequente utilização do checklist está em verificar se as medidas recomendadas ao longo do processo 163 Gestão de recursos materiais e humanos de análise de riscos foram efetivamente aplicadas o que é feito mediante a apuração de uma lista de atividades acompanhadas de boxes a serem assina lados com sim ou não Ampliando seus conhecimetos A seguir apresentamos o documento chamado Status Report ou relatório de desempenho do trabalho para que ele serve e onde deve ser utilizado Na sequência apresentamos também modelos do documento de decisão de comprar e do dicioná rio da estrutura analítica do projeto Relatório de desempenho do trabalho MONTES 2016 O relatório de desempenho do trabalho conhecido pelo termo inglês Status Report organiza e resume as informações sobre o desempenho do trabalho e apresenta análises compa rando o realizado com o planejado linha de base Ele informa a situação e o progresso no nível de detalhe requerido O gerente de projeto deve usar seu poder de sín tese já que a maioria das partes interessadas principalmente os executivos não irão ler relatórios muito extensos Uma boa prática é sumarizar todas as informações em uma ou duas páginas Usar formatos de gráficos de barras curvas S histogramas e tabelas podem ajudar a sintetizar as informações e atrair a atenção das partes interessadas Os relatórios de desempenho devem analisar a variação de desempenho usando técnicas como a análise do valor agre gado e prever o desempenho futuro Gerência de projetos em TI 164 Devem ser gerados periodicamente em formato mais simples ou mais sofisticado conforme as necessidades das partes inte ressadas Em determinados projetos é comum gerar um rela tório de desempenho mais resumido para um determinado grupo e um mais detalhado para outro grupo Os relatórios mais simples devem conter pelo menos as informações do desempenho como concluído ou indicadores de cada área escopo prazo custo e qua lidade Os mais sofisticados normalmente contemplam as seguintes informações 2 Análise do desempenho anterior 2 Situação atual dos riscos e questões 2 Trabalho concluído no período 2 Trabalho a ser concluído no próximo período 2 Resultados da análise da variação 2 Término previsto do projeto 2 Outras informações relevantes Decisão de comprar MONTES 2016 Neste relatório devem estar relacionados todos os itens a serem adquiridos É importante salientar que esses itens devem estar relacionados com a EAP do Projeto isto é devem usar o mesmo código de EAP A tabela a seguir é um modelo de como esse relatório pode ser formatado 165 Gestão de recursos materiais e humanos Tabela Relatório de decisões de compra Código Item a ser adquirido Código EAP Motivos para a compra Fornecedores potenciais Orçamento Término Fonte httpsescritoriodeprojetoscombrplanejamento349 Dicionário da EAP MONTES 2016 Este documento serve como parte de um sistema de autoriza ção de trabalho descrevendo para os integrantes da equipe cada componente da Estrutura Analítica do Projeto Pode ser utilizado para controlar quando um trabalho específico é reali zado para evitar o aumento do Escopo do Projeto e aumentar a compreensão das partes interessadas sobre o esforço neces sário para realizar cada pacote de trabalho A tabela abaixo representa um modelo de como um Dicionário de EAP pode ser formatado Cód EAP Nome do Pacote de Trabalho Data da atualização OrganizaçãoPessoa responsável Descrição do pacote de trabalho Trabalho envolvido Critérios de aceitação Gerência de projetos em TI 166 Cód EAP Nome do Pacote de Trabalho Data da atualização OrganizaçãoPessoa responsável Riscos Recursos necessários Duração Marcos do cronograma Custo Data de entrega Outras informações relevantes para a execução do pacote de trabalho como premissas interdependências requisitos contra tuais requisitos de qualidade referências técnicas entre outros Atividades 1 Explique o que significa o termo aquisição e justifique a necessidade de se ter uma gestão de aquisições para um projeto 2 Quais são os dois tipos de riscos e quais as suas características 3 Por que planejar as respostas aos riscos é tão importante quanto identificálos 4 O que é e para que serve o relatório de desempenho do trabalho Gestão de qualidade e integração do projeto Na primeira parte deste capítulo trataremos sobre a gestão da qualidade do projeto Na sequência abordaremos a gestão da inte gração do projeto e por último veremos algumas ferramentas que auxiliam na análise e no controle da qualidade dos projetos No final deste capítulo apresentamos um exemplo de caso de sucesso na gestão de projetos Apesar de o assunto desta obra tratar de gestão de projetos em TI tomamos a liberdade de inserir também exemplos de outras áreas de modo a permitir uma visão da abrangência e importância do tema 8 Gerência de projetos em TI 168 81 Gestão da qualidade do projeto Você já deve ter visto propagandas falando sobre a qualidade de um produto ou serviço de determinada empresa normalmente destacando que esta fornece o produto na qualidade desejada pelo cliente e ainda a pre ços módicos Em se tratando de projetos acontece a mesma coisa isto é os patrocinadores clientes e demais interessados normalmente querem um produto ou serviço de boa qualidade sem que precisem para tanto inves tir muito Nesse caso o termo investir não se trata apenas de dinheiro mas também de tempo e aquisição contratações e até mesmo mudanças no dia a dia da empresa Quanto menos o projeto impactar nos demais processos da empresa melhor será A metodologia aplicada pelo PMI 2013 detalha uma área do conhe cimento que justamente comenta sobre a qualidade do projeto e é sobre ela que iremos tratar agora Segundo o PMBOK PMI 2013 p 227 o gerenciamento da quali dade do projeto é responsável pelas atividades da organização que determi nam as políticas de qualidade os objetivos e as responsabilidades envolvidas para que cada entrega do projeto prevista satisfaça as expectativas dos clientes patrocinadores e interessados O Quadro 1 apresenta os processos de gerenciamento da qualidade do projeto Quadro 1 Lista de processos do gerenciamento da qualidade do projeto Grupo de processos Processos de gerenciamento da qualidade do projeto Iniciação vazio Planejamento Planejar o gerenciamento da qualidade do projeto Execução Realizar a garantia de qualidade Controle Controlar a qualidade Encerramento vazio Fonte PMI 2013 Adaptado Podemos identificar um processo muito claro de planejamento realiza ção e controle da qualidade Isto é o primeiro passo é planejar a qualidade definindo os padrões aceitáveis depois devem ser realizadas as auditorias dos 169 Gestão de qualidade e integração do projeto requisitos estabelecidos a fim de verificar se as atividades do cronograma estão sendo executadas de maneira adequada para atingir o grau de aceitabilidade necessário Por último fazse necessário o monitoramento e o registro dos resultados da execução das atividades e do nível de qualidade de cada entrega A Figura 1 apresenta a visão geral do gerenciamento da qualidade do projeto Figura 1 Visão geral do gerenciamento da qualidade do projeto 1 Planejar o gerenciamento da qualidade 1 Entradas 1 Plano de gerenciamento do projeto 2 Registro das partes interessadas 3 Registro dos riscos 4 Documentação dos requisitos 5 Fatores ambientais da empresa 6 Ativos de processos organiza cionais 2 Ferramentas e técnicas 1 Análise custobenefício 2 Custo da qualidade 3 Sete ferramentas de qualidade básicas 4 Benchmarking 5 Projeto de experimentos 6 Amostragem estatística 7 Ferramentas adicionais de pla nejamento da qualidade 8 Reuniões 3 Saídas 1 Plano de gerenciamento de qualidade 2 Plano de melhorias no processo 3 Métricas da qualidade 4 Listas de verificação da quali dade 5 Atualizações nos documentos do projeto 3 Controlar a qualidade 1 Entradas 1 Plano de gerenciamento do projeto 2 Métricas da qualidade 3 Listas de verificação da quali dade 4Dados de desempenho do trabalho 5 Solicitações de mudança apro vadas 6 Entregas 7 Documentos do projeto 8 Ativos de processos organiza cionais 2 Ferramentas e técnicas 1 Sete ferramentas de qualidade básicas 2 Amostragem estatística 3 Inspeção 4 Análise das solicitações de mu danças aprovadas 3 Saídas 1 Medições do controle da qua lidade 2 Alterações validadas 3 Entregas verificadas 4 Informações sobre o desempe nho do trabalho 5 Solicitações de mudança 6 Atualizações no plano de ge renciamento do projeto 7 Atualizações nos documentos do projeto 8 Atualizações nos ativos de pro cessos organizacionais 2 Realizar a garantia da qualidade 1 Entradas 1 Plano de gerenciamento da qualidade 2 Plano de melhorias do processo 3 Métricas da qualidade 4Medições do controle da qualidade 5 Documento do projeto 2 Ferramentas e técnicas 1 Ferramentas de gerenciamento e controle da qualidade 2 Auditorias de qualidade 3 Análise de processo 3 Saídas 1 Solicitações de mudança 2 Atualizações no plano de geren ciamento do projeto 3 Atualizações nos documentos do projeto 4 Atualizações nos ativos de pro cessos organizacionais Visão geral do gerenciamento da qualidade do projeto Fonte PMBOK 2013 p 230 Gerência de projetos em TI 170 Para o controle efetivo da qualidade foram criadas algumas técnicas que podem ser utilizadas com a finalidade de definir mensurar analisar e propor soluções para problemas que eventualmente são encontrados e interferem no bom desempenho dos processos de trabalho MAGALHÃES 2017 p 1 As sete ferramentas da qualidade são fluxograma diagrama Ishikawa folha de verificação diagrama de Pareto histograma diagrama de dispersão e cartas de controle MAGALHÃES 2017 Três dessas ferramentas serão apresentadas com mais detalhes na terceira parte deste capítulo 82 Gestão de integração do projeto Conforme vimos nos capítulos anteriores a gestão de projetos é formada por um verdadeiro mosaico de processos que precisam estar bem alinhados para que o objetivo seja ele um produto serviço ou resultado seja alcançado de acordo com as especificações de tempo e custo Certamente que entre as áreas do conhecimento presentes na metodo logia apresentada nesta obra uma delas deveria ser responsável por integrar todas as outras pois caso contrário não haveria maneira de unificar e conso lidar ações na direção do sucesso do projeto Essa área é chamada de gestão da integração do projeto e segundo o PMBOK PMI 2013 p 63 inclui as atividades e processos para identi ficar definir combinar unificar e coordenar os vários processos e atividades dentro do grupo de processos do gerenciamento do projeto Com a abordagem das características de um projeto e das áreas de conhecimento aqui estudadas fica mais fácil percebermos a necessidade de se integrar todas as áreas que compõem o universo de um projeto O Quadro 2 apresenta os processos dessa área do conhecimento de projeto 171 Gestão de qualidade e integração do projeto Quadro 2 Lista de processos do gerenciamento da integração do projeto Grupo de processos Processos de gerenciamento da integração projeto Iniciação Desenvolver o termo de abertura do projeto Planejamento Desenvolver o plano de gerenciamento do projeto Execução Orientar e gerenciar o trabalho do projeto Controle Monitorar e controlar o trabalho do projeto Realizar o controle integrado de mudanças Encerramento Encerrar o projeto ou fase Fonte PMI 2013 Adaptado Analisando o quadro podemos entender que a gestão de integração do projeto diferentemente do que acontece com as outras áreas do conheci mento está ativa nas cinco etapas do projeto isto é desde a etapa de iniciação até a etapa de encerramento Podese dizer que essa é uma gestão supervisora do projeto pois está envolvida nele a partir de seu início estabelecendo e desenvolvendo o termo de abertura do projeto até o seu fim quando o docu mento que formaliza seu encerramento é desenvolvido e assinado A seguir discorreremos sobre as características do termo de abertura do projeto 821 Desenvolver o termo de abertura do projeto Conforme verificamos nos capítulos anteriores a primeira condição para termos um projeto é a existência de um documento de autorização que justifique a necessidade do produto serviço ou resultado que se pretende desenvolver Esse documento é conhecido como termo de abertura do projeto e é desenvolvido na etapa de planejamento na gestão da integração do projeto Ele é o primeiro documento oficial do projeto que dá condições para que seja executado e reconhecido no setor departamento ou empresa dependendo da sua abrangência Gerência de projetos em TI 172 Segundo o PMBOK o principal benefício desse processo é permitir um início de projeto e limites de projeto bem definidos a criação de um registro formal do projeto e uma maneira direta da direção executiva e se comprometer formalmente com o projeto PMI 2013 p 66 A Figura 2 apresenta as entradas e saídas desse processo Figura 2 Processo de desenvolver o termo de abertura do projeto Entradas Desenvolver o termo de abertura do projeto Saídas 1 Especificação do trabalho do projeto 2 Business case 3 Acordos 4 Fatores ambientais da empresa 5 Ativos de processos organizacionais 1 Termo de abertura do projeto Fonte PMI 2013 p 66 Adaptado O documento que contém as especificações do trabalho do projeto ETP indicado nas entradas na Figura 2 referemse segundo o PMBOK PMI 2013 a uma descrição narrativa dos produtos serviços ou resultados a serem entregues por um projeto e devem informar as necessidades do negó cio a descrição do escopo do produto e o plano estratégico da empresa Assim o projeto deve estar alinhado às necessidades da empresa sejam elas estratégicas táticas ou operacionais dependendo novamente da abran gência do documento Já o denominado business case é responsável por justificar negocial mente o investimento que deverá ser realizado em todas as etapas do projeto incluindo itens como demanda de mercado solicitação de clientes avanços tecnológicos e impactos ecológicos com seus respectivos riscos Uma vez que o termo de abertura do projeto foi aprovado e assinado de forma adequada o projeto pode começar Mas qual será o plano diretivo do projeto o plano mestre de gerenciamento Esse é o documento que aborda mos no item a seguir 173 Gestão de qualidade e integração do projeto 822 Desenvolver o plano de gerenciamento do projeto Conforme vimos em cada área do conhecimento que estudamos nos capítulos anteriores o processo de planejamento do gerenciamento das áreas é realizado na etapa de planejamento O planejamento do gerenciamento do cronograma do projeto por exemplo é um processo executado na etapa de planejamento na gestão de tempo do projeto assim como ocorre com o planejamento das aquisições do projeto e assim por diante A gestão de integração tem por responsabilidade conforme afirma o PMBOK PMI 2013 p 63 definir preparar e coordenar todos os planos subsidiários gerados em cada uma das outras áreas do conhecimento e inte grálos a um plano gerencial mais completo integrado e abrangente Esse plano maior tem a função de definir qual o produto serviço ou resultado que será alcançado pelo projeto e ainda mais integrar as necessida des dos interessados e dos patrocinadores do projeto justificar a real necessi dade da execução dele além de dar a autoridade necessária para o gestor do projeto ter condições de executálo A Figura 3 apresenta as entradas e saídas desse processo Figura 3 Processo de desenvolver o plano de gerenciamento do projeto Entradas Desenvolver o plano de gerenciamento do projeto Saídas 1 Termo de abertura do projeto 2 Saídas de outros processos 3 Fatores ambientais da empresa 4 Ativos de processos organizacionais 1 Plano de gerenciamento do projeto Fonte PMI 2013 p 72 Adaptado Na Figura 3 podemos notar o item 2 das entradas do processo que está descrito como saída de outros processos Esse item referese aos demais planos de gerenciamento supracitados além das linhas de base e demais saídas e Gerência de projetos em TI 174 planos auxiliares que constam como saída etapa de planejamento nos projetos realizados nas outras áreas do conhecimento Uma vez que temos o plano de gerenciamento geral do projeto e seu termo de abertura devidamente assinado passamos para o terceiro processo da gestão de integração do projeto 823 Orientar e gerenciar o trabalho do projeto Na terceira etapa a de execução das atividades do projeto estabelecidas e ordenadas no cronograma a gestão de integração é responsável por fazer esco lhas de recursos e concessões entre objetivos e alternativas que gerem conflitos entre os interessados bem como gerenciar as dependências mútuas ou con flitos de interesse entre as áreas envolvidas no projeto Segundo o PMBOK PMI 2013 p 79 este é o processo de liderança e realização do trabalho definido no plano de gerenciamento do projeto e implementação das mudan ças para atingir os objetivos A Figura 4 apresenta as entradas e saídas desse processo Figura 4 Processo de orientar e gerenciar o trabalho do projeto Entradas Desenvolver o plano de gerenciamento do projeto Saídas 1 Plano de gerenciamento do projeto 2 Solicitações de mudança aprovadas 3 Fatores ambientais da empresa 4 Ativos de processos organizacionais 1 Lista de entregas 2 Dados de desempenho do trabalho 3 Solicitações de mudanças 4 Atualizações no plano de gerenciamento do projeto 5 Atualizações nos docu mentos do projeto Fonte PMI 2013 p 79 Adaptado 175 Gestão de qualidade e integração do projeto Repare que conforme apresentado na Figura 4 as orientações e os gerenciamentos necessitam em primeiro lugar dos documentos relaciona dos no plano de gerenciamento do projeto conforme havíamos apresentado Note também que como resultados ou saídas desse processo estão a lista de entrega e os relatórios que apresentam os dados de desempenho do trabalho De fato faz sentido pois para orientar e gerenciar o que está sendo executado é necessário ter em mãos a lista de atividades que precisam ser executadas de maneira ordenada como num cronograma definindo para cada atividade suas necessidades de recursos humanos materiais finanças etc Já o documento que apresenta os dados de desempenho do trabalho é necessário pois permite ao gestor acompanhar o resultado de cada atividade equipe de trabalho ou mesmo o desempenho do equipamento adquirido no que tange à sua eficácia e eficiência Isso posto passamos para a próxima etapa do projeto a etapa de con trole em que são executados os processos apresentados a seguir 824 Monitorar e controlar o trabalho do projeto Depois de orientar e gerenciar é preciso monitorar a execução das ati vidades e controlar quaisquer desvios nelas Nessa fase é o gestor que precisa realizar a análise e fazer os registros do progresso de cada atividade para atender aos objetivos de desempenho definidos no plano de gerenciamento do projeto É naturalmente aceitável que as partes interessadas queiram por vezes verificar a situação do projeto e até compreender o motivo de determinada atividade estar se alongando mais do que o previsto ou ter custado mais do que o que foi orçado Enfim as partes interessadas no projeto e principal mente seus patrocinadores querem e precisam estar sempre bem informadas sobre o andamento do projeto quais passos estão sendo tomados e sobre qualquer possível mudança no cronograma ou em suas linhas de base Gerência de projetos em TI 176 A Figura 5 apresenta as entradas e saídas desse processo Figura 5 Processo de monitorar e controlar o trabalho do projeto Entradas Monitorar e controlar o trabalho do projeto Saídas 1 Plano de gerenciamento do projeto 2 Previsões de cronograma 3 Previsões de custos 4 Mudança de validades 5 Informações sobre o desempenho do trabalho 6 Fatores ambientais de empresa 7 Ativos e processos organizacionais 1 Solicitações de mudança 2 Relatório de desempenho do trabalho 3 Atualizações nos planos de gerenciamento do projeto 4 Atualizações nos docu mentos do projeto Fonte PMI 2013 p 86 Adaptado Repare na figura que para se monitorar e controlar o trabalho do pro jeto é necessário além do plano de gerenciamento do projeto e da previsão da evolução da linha de base do cronograma um documento contendo as informações sobre o desempenho do trabalho em cada atividade Esse documento é resultado do processo anterior orientação e gerenciamento do trabalho do projeto Isso faz sentido pois para conseguir monitorar e controlar o trabalho executado o gestor necessita ter conhecimento do desempenho qualidade custo prazo eficácia e eficiência de cada equipe e das aquisições equipa mentos e materiais em cada atividade do projeto Note também na figura o documento de solicitação de mudanças como item 1 da lista de saídas do processo Esse documento segundo o PMBOK PMI 2013 p 85 é uma proposta formal para modificar qualquer docu mento entrega ou linha de base e pode ser iniciado interna ou externamente de modo opcional ou contratualmente obrigatório Essas solicitações devem ser empregadas quando o gestor encontrar problemas no desenvolvimento do trabalho do projeto e podem modificar vários itens tais como 177 Gestão de qualidade e integração do projeto 2 políticas ou procedimentos 2 escopo custo ou orçamento 2 cronograma ou qualidade dos projetos O Quadro 3 apresenta um modelo do que uma solicitação de mudança para o projeto pode conter Quadro 3 Modelo de solicitação de mudanças Título do Projeto Data de Início Número Solicitação de mudança Gerente Patrocinador Cliente Características Interna Externa Opcional Obrigatória Ação corretiva OPCIONAL Aqui devem estar relacionadas as atividades intencionalais que realinham o desempenho dos trabalhos do projeto com o plano de gerenciamento do projeto Ação preventiva OPCIONAL Aqui devem estar relacionadas as atividades intencio nalais para garantir que o desempenho futuro do trabalho do pro jeto esteja alinhado com o plano de gerenciamento do projeto Reparo de defeito OPCIONAL Aqui devem estar relacionadas as atividades intencionalais para modi ficar um produto ou componente de produto em não conformidade Gerência de projetos em TI 178 Atualizações OPCIONAL Lista de mudanças em documentações planos etc do projeto formalmente controlados para refletir ideias ou conteúdos modificados ou adicionados Assinatura do gerente de projeto Data Assinatura do patrocinador do projeto Data Assinatura do cliente Data Fonte PMI 2013 p 85 Adaptado Passemos então para o processo seguinte da área de gerenciamento de integração do projeto 825 Realizar o controle integrado de mudanças Esse processo também ocorre na etapa de controle do projeto e o gestor que está monitorando e controlando o trabalho de cada atividade não pode se esquecer de realizar esse controle de forma integrada isto é tendo em vista o impacto de suas ações de controle em todas as outras áreas do conheci mento e também as consequentes reações dos interessados e dos patrocina dores do projeto Segundo o PMBOK 2013 esse é o processo em que se deve Revisar todas as solicitações de mudança aprovar as mudanças e gerenciar as mudan ças sendo feitas nas entregas ativos de processos organizacionais documentos do projeto e no plano de gerenciamento do projeto e comunicar a disposi ção PMI 2013 p 94 Podemos considerar que esse processo deve permitir ao gestor que as mudanças documentais sejam feitas de forma integrada reduzindo os riscos do projeto provenientes de alterações e mudanças 179 Gestão de qualidade e integração do projeto A Figura 6 apresenta as entradas e saídas desse processo Figura 6 Processo de realizar o controle integrado de mudanças do projeto Entradas Realizar o controle integra do de mudança Saídas 1 Plano de gerenciamento do projeto 2 Relatório de desempenho do projeto 3 Solicitações de mudanças 4 Fatores ambientais 5 Ativos de processos organizacionais 1 Solicitações de mudanças aprovadas 2 Registros de mudanças 3 Atualizações do plano de gerenciamento do projeto 4 Atualizações nos docu mentos do projeto Fonte PMI 2013 p 94 Adaptado Como saída desse processo temos o documento referente à solicitação de mudanças aprovadas e o registro de mudança Este último é usado para documentar as modificações que ocorrem durante o projeto comunicando as partes interessadas sobre o impacto das mudanças no prazo custo qualidade e escopo do projeto bem como o risco agregado É importante ressaltar que as mudanças rejeitadas também devem ser registradas no documento de registro de mudanças obviamente explicando o motivo as condições o contexto envolvidos naquele caso específico para que possam ser consultadas posteriormente 826 Encerrar o projeto ou fase Finalmente na etapa de encerramento temos o processo de encerra mento do projeto que deve ser formalizado a cada encerramento de cada fase do projeto e por fim no encerramento do projeto como um todo Segundo o PMBOK PMI 2013 p 100 esse é um processo de finalização de todas as atividades de todos os grupos de processos de gerenciamento do projeto para encerrar formalmente o projeto ou a fase É muito importante que o gestor revise todas as entregas linha de base do escopo e assegure toda sua equipe e os interessados de que os objetivos do projeto foram alcançados Gerência de projetos em TI 180 Caso seja identificado que o projeto teve seu pedido de formalização de encerramento feito antes de atingir seus objetivos esse processo de encer ramento deve disparar atividades para a verificação e a documentação dos motivos que levaram a tal situação Como resultado do encerramento temos a lista de lições aprendidas a liberação dos recursos materiais e humanos disponibilizados para o projeto e o documento que formaliza o seu encerramento A Figura 7 apresenta as entradas e saídas desse processo Figura 7 Processo de encerrar o projeto ou fase Entradas Encerramento do projeto ou fase Saídas 1 Plano de gerenciamento do projeto 2 Entregas aceitas 3 Ativos de processos organizacionais 1 Transição do produto serviço ou resultado final 2 Atualização dos ativos de processos organizacionais Fonte PMI 2013 p 100 Adaptado Repare na Figura 7 que o item 1 das entradas é o plano de gerencia mento do projeto Esse documento conforme vimos no início deste capítulo é a unificação e o agrupamento organizado de todos os planos de gerencia mento gerados por todas as demais áreas do conhecimento do projeto Ele permite uma visão geral unificada e integrada de tudo que precisa ser feito para que o produto serviço ou resultado do projeto seja atingido De posse desse documento o gestor precisa então do item 2 entregas aceitas Esse segundo documento apresenta a formalização de todas as entre gas realizadas no decorrer do projeto e que foram aceitas dentro do padrão de qualidade custo e prazo definidos É simples entender que se tivermos todas as entregas previstas no plano de gerenciamento de projeto aceitas e forma lizadas teremos o produto serviço ou resultado esperado e o projeto poderá ser finalizadoencerrado 181 Gestão de qualidade e integração do projeto Finalizamos aqui o estudo sobre o gerenciamento da integração do projeto A proposta não é esgotar o tema nem abordálo de todas as pers pectivas mas sim trazer considerações e fatos que auxiliem no entendi mento de como esse processo funciona bem como dar condições para um futuro aprofundamento Passamos agora para a terceira parte deste capítulo que trata de apresen tar alguns casos de sucesso no que tange à gestão de projetos 83 Ferramentas da qualidade 831 Diagrama de causa e efeito O diagrama de causa e efeito tratase conforme Bazoni et al 2015 p 232 de uma ferramenta que permite identificar e analisar as potenciais causas de variação do processo que impactam na qualidade do produtoresul tado Esse diagrama foi criado por Kaoru Ishikawa 19151989 em 1943 Segundo Werkema 1995 apud BAZONI et al 2015 p 233 para a montagem do diagrama devem ser seguidas as seguintes etapas 2 definir o problema a ser estudado 2 estudar e conhecer o processo envolvido por meio de observação documentação e troca de ideias com pessoas envolvidas 2 discutir o problema em reunião 2 coletar informações e organizálas em causas principais secundárias terciárias eliminando informações não relevantes e sem importância 2 montar o diagrama e validar com os envolvidos A figura a seguir apresenta um exemplo de utilização do diagrama de Ishikawa no caso de acidentes de trabalho em uma indústria Acidentes podem ocorrer por exemplo quando há falta de materiais para o trabalho como luvas e quando trabalhadores se distraem por conta de cansaço no decorrer das atividades As linhas do diagrama demonstram os fatores que fazem parte do cenário analisado Gerência de projetos em TI 182 Figura 8 Diagrama de Ishikawa problema Materiais Falta de luvas Treinamento Métodos Antiquadas Trabalhadores Distração por cansaço Máquinas Acidentes de trabalho Fonte KOSCIANSKI SOARES 2007 p 20 832 Mapas de processos Os mapas de processos ou fluxogramas são representações gráficas de cada um dos passos na sequência de um processo SALGADO 2008 p 15 Já o PMBOK PMI 2013 p 236 define o fluxograma como uma ferra menta que além de apresentar a sequência de etapas do processo mostra as possibilidades de ramificações existentes para transformar uma ou mais entradas em uma ou mais saídas do processo A Figura 9 apresenta um exemplo de fluxograma para compras Figura 9 Exemplo de fluxograma Solicitação de compra Seleção de potenciais fornecedores para compra Pesquisa e cotação de preços Definição Qualificar Efetuar a compra Não Não Sim Sim Fornecedor qualificado Possível qualificar Fonte SALGADO 2008 p 15 183 Gestão de qualidade e integração do projeto 833 Diagrama de Pareto Conforme afirma o PMBOK PMI 2013 p 237 esse diagrama apresenta gráficos de barras verticais usadas na identificação de algumas fontes críticas responsáveis pela maioria dos efeitos de um problema Já Campos 2004 apud SALGADO 2008 p 14 afirma que a análise de Pareto divide um problema grande em problemas menores e mais fáceis de serem resolvidos separando o problema em duas classes de causas poucas vitais e muitas triviais Nesse contexto um problema pode possuir muitas causas mas pou cas apresentam grande impacto ou grande perda sendo que as demais 80 delas são apenas triviais ou irrelevantes Para se montar um diagrama de Pareto é preciso seguir os seguintes passos 2 Identificar cada categoria de problema que pode impactar no projeto 2 Calcular o valor percentual que deve ser atribuído a cada uma des sas categorias 2 Traçar um gráfico XY no qual o eixo Y representa a linha de percentagem cumulativa que apresenta o total em que cada categoria de problema representa para o projeto como um todo 2 Como o problema mais frequente ou mais caro sempre é o pro blema mais importante devese responder à pergunta Qual categoria de problema apresenta maior impacto sobre os objeti vos do projeto 2 Devese levar em conta não apenas as perdas financeiras ou de prazo do projeto mas também as perdas relativas à boa imagem da empresa perante o cliente e a sociedade Gerência de projetos em TI 184 A Figura 10 a seguir apresenta um exemplo de gráfico de Pareto Figura 10 Gráfico de Pareto 25 20 15 10 5 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 100 itens verificados 90 80 70 60 50 40 30 20 10 0 Ocorrências Percentual acumulado Fonte MARIANO PEREIRA GOMES 2012 p 549 Além das ferramentas abordadas também podem ser utilizados 2 folhas de verificação 2 histogramas 2 gráficos de controle 2 diagrama de dispersão Finalizamos aqui a terceira parte deste capítulo O intuito foi apresentar as características da gestão da qualidade e da gestão da integração do projeto sem obviamente pretender esgotar esse importante tema Ampliando seus conhecimentos O mundo da gestão de projetos sempre rende boas histó rias e lições aprendidas e elas são ainda melhores quando o 185 Gestão de qualidade e integração do projeto projeto obteve êxito atingiu seus objetivos e seu produto serviço ou resultado agregou valor aos processos empresariais do contratante Apresentamos a seguir um exemplo de caso de sucesso entre vários disponíveis É interessante verificar que dificuldades foram superadas e objetivos foram atingidos apesar dos obstáculos Volkswagen do México produção de peças para o automóvel Jetta PMI 2017 p 12 Para se preparar para a produção de seu novo Jetta a Volkswagen voltouse para uma combinação de plantas inter nacionais e fornecedores externos para produzir partes do novo motor e conjuntos de eixos do carro A Volkswagen Mexico Components VW México ganhou uma licitação para produzir vários componentes incluindo os eixos dianteiros e montagem dos módulos laterais A equipe da fábrica VW México tinha 21 meses e um orçamento de US 33 milhões EUA para projetar e instalar a linha de montagem e começar a produção em massa de peças Histórico A VW do México venceu a licitação para o projeto pro pondo um custo fixo para a produção de peças Isso sig nificava que não haveria espaço para derrapagens no orça mento Qualquer trabalho que ultrapassasse o orçamento seria incorrido como uma perda O gerente de projeto e equipe teria que desenvolver processos internos para outras equipes seguirem A produção do eixo dianteiro e a montagem do módulo lateral foram supervisionadas por um Project Management Professional PMP e o projeto foi um dos primeiros a ser gerenciado pelo escritório de projeto da VW México o qual Gerência de projetos em TI 186 forneceu supervisão a todo o portfólio de programas e proje tos da produção de componentes do Jetta Além disso um novo fornecedor foi selecionado para o projeto enquanto o processo de aquisição de equipamentos estava em andamento Esta adição tardia resultou num atraso de dois meses na aquisição das linhas de montagem Desafios A equipe VW México vinha utilizando processos de gestão padrão conforme descrito em Um Guia do Conhecimento em Gerenciamento de Projetos Guia PMBOK para completar o projeto de linha de montagem dentro do prazo e orçamento Para supervisionar o projeto complexo a VW México esta beleceu um escritório de projetos PMO que era respon sável por monitorar e controlar o orçamento global e crono grama para os projetos relacionados ao Jetta Uma vez que a VW do México foi agraciada com o projeto de montagem o PMO trabalhou junto com o departamento financeiro para obter os recursos necessários Um gerente de projeto foi selecionado e o gerente do departamento de manufatura foi nomeado o patrocinador do projeto O gerente de projeto apoiado por um membro do depar tamento de planejamento integrou os planos apresentados pelos diversos participantes do projeto para desenvolver uma estrutura analítica do projeto EAP e linha do tempo deta lhada para o projeto global A EAP serviu como um roteiro para cada fase do projeto Enquanto os departamentos de produção e qualidade foram envolvidos ao longo do pro jeto outros departamentos poderiam ser consultados sempre que necessário O gerente do projeto foi responsável pela supervisão da EAP e em envolver outros departamentos nos momentos adequados 187 Gestão de qualidade e integração do projeto Solução Desde a iniciação até o fechamento o projeto foi dividido em cinco fases com nove etapas ao longo de dois anos O cro nograma incluía todo o trabalho de aquisição e fabricação de equipamentos através de testes de linha de montagem e oti mização A fase final terminou com o início da produção e a montagem do eixo do módulo lateral Um plano da qualidade correspondente foi desenvolvido utilizando os padrões da fábrica de componentes que foi integrado na linha do tempo Para garantir que o projeto seria concluído a tempo o gerente de projeto encontrou formas criativas para resolver questões de calendário criadas no início do processo Para compen sar o atraso de dois meses no recebimento de equipamentos da linha de montagem o grupo realizou um treinamento de fabricação enquanto o grupo de manutenção acompanhou a empresa subcontratada na instalação do equipamento da linha de montagem Ao realizar estes dois eventos simulta neamente o gerente do projeto impediu atrasos futuros que pudessem causar novos atrasos no projeto Ao longo do projeto o PMO manteve supervisão para o orçamento geral do projeto Outros elementos do projeto foram monitorados por membros da equipe do projeto Por exemplo um membro da equipe de planejamento monitorou atividades relacionadas com a EAP e o plano de qualidade enquanto um membro da equipe de qualidade foi responsá vel por garantir que as partes satisfizessem as especificações de qualidade da empresa Ao término de cada fase do projeto a equipe do projeto analisava o estado geral do projeto e realizava identificação de riscos para as fases restantes Todas as alterações resultantes da EAP foram aprovadas pelo gerente do projeto e pelo patro cinador do projeto Gerência de projetos em TI 188 O fim do projeto foi marcado pela transição para equipe de produção O encerramento oficial do projeto ocor reu 12 semanas depois que a produção do componente inicial começou Atividades 1 Defina integração 2 Escreva sobre o documento do plano de gerenciamento do projeto 3 Discorra sobre a etapa de encerramento do projeto 4 Pesquise e descreva brevemente sobre cada uma das sete ferramentas básicas da qualidade abordadas neste capítulo Gabarito Gerência de projetos em TI 190 1 Introdução à gestão de projetos em TI 1 Escopo custo prazo qualidade integração riscos comunicação aquisições e recursos humanos partes interessadas 2 Não A metodologia estabelece apenas as chamadas melhores práticas para o projeto que devem ser utilizadas tendo em vista a cultura orga nizacional em que cada projeto está sendo desenvolvido 3 Metodologia segundo Medrano 2012 p 6 é um conjunto ou sistema de métodos princípios e regras para regulamentar determi nada disciplina 4 Iniciação planejamento execução controle e encerramento ou fi nalização 2 Escritório de gerenciamento de projetos 1 Saiba o que você pretende alcançar tenha um patrocinador executi vo crie um manual de relacionamento para o PMO coloque o PMO a cargo de processos e não de medidas punitivas selecione softwares de gerenciamento de projetos 2 A menos adequada é a estrutura organizacional funcional porque a estrutura é dividida por feudos de especialidades com hierarquias bem definidas Não possui a figura do gerente de projetos e o proje to fica a cargo de gerentes funcionais subdivididos ente eles que por sua vez normalmente dão prioridade às atividades restritas ao seu departamento em detrimento das atividades relativas ao projeto Também pode ser mencionado que o projeto não possui um gerente que faz a integração de todas as partes 191 Gabarito 3 É considerada utópica porque os projetos não vão utilizar a todo momento todos os recursos humanos e materiais disponibilizados gerando assim ociosidade desses recursos Em se tratando de empresas ou indústrias que visem ao lucro em suas atividades o fato de estar com recursos ociosos não é visto com bons olhos e por isso normal mente os projetos não são aprovados 4 Não O PMO não surgiu em decorrência do crescimento da TI Po rém com o crescimento da importância e abrangência da TI dentro das empresas justificase a utilização de técnicas de gestão de projetos para gerenciar projetos da área 3 Auditoria de TI 1 São características numéricas gerenciáveis pois somente o que é me dido pode ser gerenciado e o gerenciamento permite a busca por melhores resultados 2 Para se identificar qual a situação atual de um projeto ou atividade devemos medir as características relevantes desse projeto ou atividade ou seja para uma auditoria adequada é necessário ter os pontos de controle bem determinados e medidos 3 Um ponto de controle é uma característica ou documento gerado enviado ou recebido que está sob observação Caso esse ponto de controle se mostre instável e sua instabilidade for impactante ao pro jeto ele se tornará um ponto de auditoria deverá sofrer as correções necessárias para seu correto funcionamento e passar por uma nova vistoria a fim de se verificar se o problema foi corrigido Gerência de projetos em TI 192 4 Tópicos especiais de gestão de projetos de TI 1 É ruim Por que se o processo não tiver nenhum caminho alternativo para as atividades que o compõem nenhum erro poderá acontecer no caminho principal pois caso ocorra uma exceção acontecerá e o processo irá travar Resumindo se não houver alternativa o processo deve ser realizado com perfeição caso contrário ele trava 2 É bom Um processo que não possui exceção significa que nunca vai travar independentemente do que aconteça sempre haverá uma alternativa possível 3 Procedimento operacional padrão é um documento que define as regras que devem ser cumpridas para a execução de uma determina da atividade Define também quem é o responsável por cobrar que a atividade seja realizada de acordo com as regras o material necessário para se executar a atividade esclarece seu manuseio e principalmen te define o que vai acontecer com a pessoa que não respeitar as regras definadas por esse procedimento padrão isto é quais sãos as ações corretivas 4 As ações corretivas contêm a descrição das punições que devem ser aplicadas ao funcionário que descumprir deliberadamente as regras definidas pelas atividades críticas do POP ou pelo manuseio do material 5 As áreas do conhecimento da gestão de projetos 1 É o local bem determinado a que se aponta para atingir ou o ob jetivo que se pretende atingir ou ainda o limite ou abrangência de uma operação 193 Gabarito 2 EAP é a estrutura analítica do projeto É uma lista detalhada dos entregáveis do projeto e das atividades que necessitam ser executadas para criar um produto ou serviço 3 Fluxograma Planejar o gerenciamento do escopo Coletar requisitos Definir escopo Validar escopo Controlar escopo 4 Devem ser contemplados os seguintes itens 2 a descrição do que se espera atingir com a implementação do pro jeto seu produto ou serviço 2 os fatores de sucesso e critérios de êxito 6 Gestão de tempo e recursos humanos 1 Dependência obrigatória as dependências obrigatórias são as exigidas legal ou contratualmente ou inerentes à natureza do trabalho PMI 2013 p 157 Dependência arbitrada as dependências arbitradas são estabelecidas com base no conhecimento das melhores práticas numa área de apli cação específica ou em algum aspecto singular do projeto em que uma sequência específica é desejada mesmo que haja outras sequên cias aceitáveis PMI 2013 p 157 Gerência de projetos em TI 194 Dependência externa as dependências externas envolvem uma rela ção entre as atividades do projeto e as não pertencentes ao projeto PMI 2013 p 157 Dependência interna as dependências internas envolvem uma rela ção de precedência entre as atividades do projeto e estão geralmente sob o controle da equipe do projeto 2 Término para Início TI exemplo uma cerimônia de entrega de prêmios sucessora não pode começar até que a corrida predecessora termine Início para Início II exemplo a nivelação do concreto sucessora não pode ser iniciada até que a colocação da fundação predecessora seja iniciada Término para Término TT exemplo a redação de um documento predecessora deve ser terminada antes que o documento seja edita do sucessora Início para Término IT exemplo o primeiro turno da guarda de segurança sucessora não pode terminar até que o segundo turno da guarda de segurança predecessora comece 3 O processo em questão possui dois caminhos O primeiro ABD tem seu tempo estimado em 25 unidades de tempo O segundo ACD tem seu tempo estimado em 30 unidades de tempo e por isso é o caminho crítico do projeto Isso posto temos como conse quência que o primeiro caminho possui uma folga de 5 unidades de tempo para ser realizado e o segundo caminho não possui folga Essa folga de 5 unidades de tempo reside sobre a atividade B Temos por consequência que a única atividade que pode iniciar ou finalizar 5 unidades de tempo mais cedo ou mais tarde é a atividade B 195 Gabarito 4 Segundo Vargas 2012 uma linha de base nada mais é do que uma foto sobre os detalhes do projeto ou seja um retrato do contexto do projeto fornecendo um padrão que proporciona referência para alguma comparação Vargas 2012 diz ainda que um projeto sem linhas de base não é controlado Concluise que as linhas de base são os conjuntos de de talhamentos dos aspectos mapeados em cada área de conhecimento planejados para atendimento à forma de condução mais eficaz em prol do sucesso de um empreendimento 7 Gestão de recursos materiais e humanos 1 Aquisição significa o ato de adquirir e adquirir significa alcançar a posse de ou obter Em se tratando de gestão de projetos é correto pensar que alguns materiais ou equipamentosdispositivos precisarão ser comprados ou locados para que uma determinada atividade do projeto seja executa da adequadamente Fornecedores deverão ser consultados orçamen tos precisarão ser analisados datas de início e de liberação do recurso material deverão ser controladas entre outros Sendo assim fazse necessário a gestão de compra ou locação desses materiais ou o geren ciamento das aquisições do projeto 2 Existem dois tipos de riscos o risco puro e o risco especulativo O risco puro tem por característica tratar problemas materiais que ge ram perda para o projeto tais como risco de incêndio de terremotos de acidente ou de adoecimento de integrantes da equipe etc O risco especulativo trata fatores dinâmicos que podem impactar no projeto tais como flutuação da bolsa de valores ou do dólar decisões Gerência de projetos em TI 196 estratégicas equivocadas que causem impacto negativo no projeto entre outros 3 Precisamos saber como proceder quando algo de ruim tem impacto sobre o processo Se existe o risco de acontecer algo ruim alguém tem que saber o que fazer quando isso ocorrer caso contrário o clima de tensão do projeto se tornará insuportável 4 O relatório de desempenho do trabalho conhecido pelo termo em inglês Status Report organiza e resume as informações sobre o desem penho do trabalho e apresenta análises comparando o realizado com o planejado linha de base Ele informa a situação e o progresso no nível de detalhe requerido O gerente de projeto deve usar seu poder de síntese já que a maioria das partes interessadas principalmente os executivos não irão ler relatórios muito extensos 8 Gestão de qualidade e integração do projeto 1 Integração é uma das dez áreas do conhecimento detalhadas pela metodologia utilizada pelo PMI e é o processo que tem como ob jetivo unificar as ações e resultados das demais áreas para que tudo aconteça em uníssono sem discrepâncias erros de comunicação e demais problemas que certamente rondam as atividades que envol vem muitas pessoas 2 Cada uma das áreas do gerenciamento de projeto é obrigada segundo a metodologia utilizada pelo PMI a gerar um documento chamado de plano de gerenciamento A gestão do escopo deve gerar o documen to chamado plano de genciamento do escopo a gestão de tempo deve gerar o plano de gerenciamento do cronograma e assim por diante para as demais áreas O fato é que na gestão de integração o documen to chamado de plano de gerenciamento da integração do projeto deve 197 Gabarito como o próprio nome diz integrar todos os outros planos de geren ciamentos gerados compondo um o principal e mais abrangente que tem como função nortear a execução das atividades o controle e o monitoramento de resultados e as solicitações de mudanças durante todo o projeto 3 Encerrar o projeto é um processo que deve ser realizado com cuidado Devem ser verificadas a conclusão e a aceitação de todas as atividades contidas no cronograma devem ser desfeitos os contratos com os fornecedores de mão de obra e de equipamentos deve ser feita uma reunião de aceitação do produto serviço ou resultado do projeto e só depois de aprovados e assinados todos os documentos é que o projeto pode ser dado como terminado oficialmente 4 2 Fluxograma O fluxograma tem como finalidade identificar o caminho real e ideal para um produto ou serviço com o objetivo de identificar os desvios É uma ilustração sequencial de todas as etapas de um processo mostrando como cada etapa é relacionada Utiliza símbolos facilmente reconhecidos para denotar os diferen tes tipos de operações em um processo 2 Diagrama Ishikawa Tem como finalidade explorar e indicar todas as causas possíveis de uma condição ou um problema específico O diagrama de causa e efeito foi desenvolvido para representar a relação entre o efeito e todas as possibilidades de causa que podem contribuir para esse efeito O diagrama foi desenvolvido por Kaoru Ishikawa da Universidade de Tóquio em 1943 e utilizado para explicar para o grupo de engenheiros da Kawasaki Steel Works como vários fatores podem ser ordenados e relacionados 2 Folhas de verificação São tabelas ou planilhas simples usadas para facilitar a coleta e análise de dados O uso das folhas de verificação economiza tempo eliminando o trabalho de se desenhar figuras ou escrever números repetitivos São formulários planejados nos Gerência de projetos em TI 198 quais os dados coletados são preenchidos de forma fácil e concisa Registram os dados dos itens a serem verificados permitindo uma rápida percepção da realidade e uma imediata interpretação da situação ajudando a diminuir erros e confusões 2 Diagrama de Pareto Tem como finalidade mostrar a importância de todas as condições a fim de escolher o ponto de partida para solução do problema e identificar a causa básica deste e monitorar o sucesso desse processo Velfredo Pareto foi um economista italiano que descobriu que a riqueza não era distribuída de maneira uni forme Ele formulou que aproximadamente 20 do povo detinha 80 da riqueza criando uma condição de distribuição desigual Os diagramas de Pareto podem ser usados para identificar os pro blemas mais importantes pelo uso de diferentes critérios de medi ção como frequência ou custo 2 Histograma O histograma tem como finalidade mostrar a distri buição dos dados por um gráfico de barras indicando o número de unidades em cada categoria Ele é um gráfico de representação de uma série de dados 2 Diagrama de dispersão Mostra o que acontece com uma variá vel quando a outra muda para testar possíveis relações de causa e efeito 2 Cartas de controle São usadas para mostrar as tendências dos pon tos de observação em um período de tempo Os limites de controle são calculados aplicandose fórmulas simples aos dados do pro cesso As cartas de controle podem trabalhar tanto com dados por variável mensuráveis como com dados por atributo discretos 199 Referências Referências Gerência de Projetos em TI 200 ABNT Associação Brasileira de Normas Técnicas NBR ISO 10006 Gestão da qualidade Diretrizes para a qualidade no gerenciamento de Projetos Rio de Janeiro 2000 AGUIAR M C Análise de causa raiz levantamento dos métodos e exem plificação 153 f Dissertação Mestrado em Engenharia de Produção Pontifícia Universidade Católica do Rio de Janeiro Rio de Janeiro 2014 Disponível em httpswwwmaxwellvracpucriobr2343723437PDF Acesso em 31 jul 2017 ARIMA C H Auditoria de sistemas computadorizados Revista de Administração São Paulo v 28 n 3 p 2232 julset 1993 BARBOSA F U N Gerenciamento de projetos o impacto do uso de indi cadores de desempenho no resultado do projeto Produto Produção v 10 n 1 p 3853 fev 2009 BAZONI A A et al A Implantação do diagrama de Ishikawa em uma empresa do segmento de tintas e materiais para construção para solucionar problemas de estocagem e recebimento Gestão em Foco n 7 p 227238 2015 BUARQUE S Como auditar a TI Disponível em httpauditoriadeti combrauditoriadeti3html Acesso em 14 jan 2017 CAMPOS R A LIMA S M P D Mapeamento de processos importân cia para as organizações Universidade Federal Rural do Rio de Janeiro Rio de Janeiro mar 2012 Disponível em httpwwwufrrjbrcodepmaterial cursosprojetomapeamentoMapeamentoProcessospdf Acesso em 16 jul 2017 CAMPOS V F Gerenciamento da rotina do trabalho do dia a dia 8 ed Nova Lima INDG Tecnologia e Serviços 2004 CNASI Segurança da Informação Auditoria de TI a transparência na tecnologia da informação 13 jul 2012 Disponivel em httpwwwcnasi combrauditoriadeti Acesso em 12 jan 2017 201 Referências CODAS M M Gerência de projetos uma reflexão histórica Scielo Brasil Revistra de Administração de Empresas v 27 n 1 p 3337 1987 CORREIA S M A Fatores críticos de sucesso da governança das TI 2010 171 f Dissertação Mestrado em Gestão de Sistemas de Informação Universidade Técnica de Lisboa Lisboa abr 2010 Disponível em http wwwrepositoryutlptbitstream10400522161Factores20Criticos20 de20sucesso20da20governana20das20TI202020 Documento20Finalpdf Acesso em 16 jul 2017 COSTA S R RAMOS A F Modelo de maturidade em gerenciamento de projeto um estudo de caso aplicado a projetos de petróleo e energia Revista Eletrônica Sistemas Gestão v 8 n 3 p 234243 2013 DÁVILA M PMBOK e gerenciamento de projetos 11 jul 2015 Disponível em httpwwwmhavilacombrtopicosgestaopmbokhtml Acesso em 26 jun 2017 DINSMORE P C Manual de gerenciamento de projetos Trad A Cavalieri 2 ed Rio de Janeiro Brasport 2009 ESCRITÓRIO DE PROJETOS Material sobre metodologia e grupos de processos de gerenciamento de projetos 2016 Disponível em http escritoriodeprojetoscombrmaterialsobremetodologiaegruposdepro cessosdegerenciamentodeprojetos Acesso em 15 jul 2016 ESPÍNDOLA J Conceitos básicos para a elaboração de projetos Dourados MS Superintendência de Planejamento e Orçamento 2006 FGV Fundação Getúlio Vargas Gannt Disponível em httpwww5 fgvbrctaepublicacoesNingPublicacoes00ArtigosJogoDeEmpresas KaroshiglossarioGANTThtml Acesso em 1 jan 2017 FORESTI A Guia de gerenciamento de projetos sistemas organizacio nais maio 2015 Disponível em httpswwwoficinadanetcombrpost 14646guiapmboksistemasorganizacionais Acesso em 16 jul 2017 Gerência de Projetos em TI 202 GARCIA C S et al Auditoria em sistemas de informação trilhas de auditoria Universidade Católica de Brasília Brasilia DF 2005 Disponível em httpwwwlyfreitascombrantartigosmbaarttrilhaauditoriapdf Acesso em 27 jul 2017 GOIÁS Secretaria de Estado de Gestão e Planejamento SEGPLAN Boas práticas referencial nov 2016 Disponível em httpwwwsegplango govbrindexphpoptioncomcontentviewarticleid19379boaspra ticasreferencialcatid346Itemid647 Acesso em 20 jul 2017 GOLLA D As principais dificuldades de implantar metodologia de gerenciamento de projeto nas empresas 2011 Monografia Especialização em Gestão de Projetos Universidade Candido Mendes Rio de Janeiro 2011 GRATERON I R G Auditoria de gestão utilização de indicadores de ges tão no setor público Caderno de Estudos FIPECAFI São Paulo p 18 maioago 1999 HAMMER M CHAMPY J Reengineering the corporation a manifesto for business revolution New York Harper Business 1994 HELDMAN K Gerência de projeto fundamentos Trad J Simões 5 ed São Paulo Elsevier 2005 INFOESCOLA Frederick W Taylor Disponível em httpwwwinfoes colacombiografiasfredericktaylor Acesso em 20 mar 2017 KERZNER H Gestão de projetos as melhores práticas Trad C B Andrei Porto Alegre Bookman 2017 KIISEL TY One of the greatest project management successes of the 19th century 2010 Disponível em httpswwwprojectmanagement comblogpost1769OneoftheGreatestProjectManagementSuccesses ofthe19thCentury Acesso em 16 jul 2017 LARSON E W GRAY C F Gerenciamento de projetos o processo gerencial Trad de T Amon Porto Alegre AMGH 2016 203 Referências MACHADO A S Gestão de projetos inovadores o perfil do gestor Faculdades Integradas Pedro Leopoldo Pedro Leopoldo 2009 Disponível em httpwwwfpledubr2013mediapdfsmestradodissertacoes2009 dissertacaoagdamachado2009pdf Acesso em 16 jul 2017 MAGALHÃES J M As 7 ferramentas da qualidade modelos de gestão Disponível em httpwwwaprendersempreorgbrarqs920207fer ramentasqualidadepdf Acesso em 31 jul 2017 MARIANO S PEREIRA F GOMES B J Melhoria dos serviços de TI através da aplicação de um modelo de governança e ferramentas de qualidade Sistemas Gestão n 7 p 546553 2012 MARTINS R Método do caminho crítico Blog da Qualidade set 2012 Disponível em httpwwwblogdaqualidadecombrmetododocaminho critico Acesso em 16 jul 2017 MASSOT E V D A Metodologias em gerenciamento de projetos e sua implantação em tecnologia da informação TI Produção Acadêmica Rio de Janeiro p 15 jan 2008 Disponivel em httpwwwadministradores combrproducaoacademicametodologiasemgerenciamentodeprojetos esuaimplantacaoemtecnologiadainformacaoti475 Acesso em 16 jul 2017 MAXIMIANO A C Administração de projetos como transformar ideias em resultados 2 ed São Paulo Atlas 2002 MEDRANO R Putting PMBOK into project management Deloitte Global Services Limited 2012 Disponível em httpspmiocorg componentdocmandocdownload245deloittepmiocpresentation 20121009Itemid58 Acesso em 26 jul 2017 MELLO A E Aplicação do mapeamento de processo e da simulação no desenvolvimento de projetos de processos produtivos Universidade Estadual de Itajubá Itajubá 2008 Disponível em httpwwwiepgunifei edubrarnaldodownloaddissertacoesAna20Emiliapdf Acesso em 16 jul 2017 Gerência de Projetos em TI 204 MICHAELIS Dicionário Brasileiro da Língua Portuguesa Adjudicar Disponível em httpmichaelisuolcombrbuscaidMp0z Acesso em 22 ago 2017 MONTES E Relatórios de desempenho de projeto nov 2016 Disponível em httpsescritoriodeprojetoscombr Acesso em 12 fev 2017 MURAKI Fundação de Apoio Institucional Modelagem de projetos o que é um projeto jan 2014 Disponível em httpsvalberluciocom modelagemdeprojetosoqueeumprojeto Acesso em 26 jul 2017 NETPROJECT Como estruturar um PMO Disponível em http netprojectcombrblogebookcomoestruturarumpmo Acesso em 10 jul 2017 OLIVEIRA F S O que é tecnologia da informação 2016 Disponível em httpblogunipebrgraduacaooqueetecnologiadainformacao Acesso em 10 jul 2017 OLIVEIRA W A et al Maturidade em gerenciamento de projetos visão geral e análise comparativa de 4 modelos 2004 85 f Monografia MBA em Gerência de Projetos Fundação Getulio Vargas Belo Horizonte 2004 PAIVA A Gerente de projetos CPM Critical Path Method jul 2011 Disponível em httpgerentedeprojetonetbrmetododocaminhocriti coparte13 Acesso em 6 abr 2017 PEREIRA V TEIXEIRA A O que é um projeto Modele seu projeto 2014 Disponivel em httpsvalberluciocommodelagemdeprojetoso queeumprojeto Acesso em 29 dez 2016 PINHEIRO J M S Auditoria e análise de segurança da informação segurança física e lógica Centro Universitário Geraldo Di Biasi 2009 Disponível em httpswwwprojetoderedescombraulasugbaudito riaeanaliseugbapoioauditoriaeanalisedesegurancaaula02pdf Acesso em 27 jul 2017 PMBOK P PMBOK Project Management Body of Knowledge Belo Horizonte PMI MG 2000 205 Referências PMBOK P PMBOK Project Management Body of Knowledge Guia PMBOK Pennsylvania Project Management Institute 2013 PMI Project Management Institute Estudo de caso Disponível em httpbrasilpmiorgbrazilknowledgecentermedia20D4F81EB B924A2C913FE3743CC4EBDDashx Acesso em 16 jul 2017 Um guia do conhecimento em gerenciamento de projetos Guia PMBOK 5 ed Pennsylvania Project Management Institute 2013 PORTAL ADMINISTRAÇÃO Entenda a diferença entre eficiência e efi cácia Disponível em httpwwwportaladministracaocom201507dife rencaentreeficienciaeeficaciahtml Acesso em 1 jan 2017 PRADO D Maturidade em gerenciamento de projetos Belo Horizonte INDGTecs 2008 PROCHNOW M SCHAFFER B Pequeno manual para elaboração de projetos Instituto Socioambiental 2001 Disponível em httpprgime nezdominiotemporariocomdocelaboracaodeprojetospdf Acesso em 26 jul 2017 PROJETOS E TI O que é um PMO 14 jan 2013 Disponível em http projetoseticombroqueumpmoescritoriodeprojetosintroducaowsa endnote13 Acesso em 28 jun 2017 RECCHIA R O que é projeto Qual sua importância para o mercado de trabalho 2015 Disponível em httpscorporatecanaltechcombrnoticia gestaoafinaloqueeumprojetoqualsuaimportanciaparaomercadode trabalho49217 Acesso em 26 dez 2016 REIS T Project Managemente Office tudo o que você precisa saber Project Builder 22 abr 2016 Disponível em httpwwwprojectbuildercombr bloghomeentryprojetosprojectmanagementofficetudooquevocepre cisasaber Acesso em 10 jul 2017 RIBEIRO R P GARCIA T D C Redefinição de linhas de base e seus reflexos no gerenciamento do tempo TecHoje Disponível em httpwww techojecombrsitetechojecategoriadetalheartigo1467 Acesso em 28 jul 2017 Gerência de Projetos em TI 206 RUPPENTHAL J E Gerenciamento de riscos Colégio Técnico Industrial de Santa Maria Santa Maria 2013 Caderno Técnico SALGADO L S O sistema de excelência em gestão e sua implantação em uma empresa de mineração e construção 2008 Monografia Bacharelado em Engenharia da Produção Universidade Federal de Juiz de Fora Juiz de Fora 2008 SAMBATECH O que é um projeto 2009 Disponível em httpsamba techcombloginsightsoqueeumprojeto Acesso em 10 jul 2017 SCHAEFER JÚNIOR D P et al Projeto de extensão universitária uma análise comparativa com o Guia PMBOK 2016 Disponível em http wwwadmpgcombr2016downphpid2136q1 Acesso em 28 jun 2017 SCHWABER K SUTHERLAND J Guia do SCRUM ScrumOrg and ScrumInc 2013 Disponível em httpswwwscrumguidesorgdocs scrumguidev1ScrumGuidePortugueseBRpdf Acesso em 26 jul 2017 SENA C de Quem não controla não gerencia Administradorescom 2 maio 2016 Disponível em httpwwwadministradorescombrartigos negociosquemnaocontrolanaogerencia95097 Acesso em 27 jul 2017 SGANDERLA K BPMN modelando corretamente o fluxo de sequência de atividades 17 maio 2012 Disponível em httpblogiprocesscom br201205bpmnmodelandocorretamenteofluxodesequenciadeativi dades Acesso em 29 jun 2017 SIGNIFICADOS Auditoria Disponível em httpswwwsignificados combrauditoria Acesso em 13 jan 2017 SILVA A O que é TI 2015 Disponível em httpwwwadamsilvacom brtecnologiaoqueeti Acesso em 10 jul 2017 SILVA D Gestão de projetos usando diagrama de redes para gerenciar o tempo Blog da Qualidade ago 2015 Disponível em httpwwwblogda qualidadecombrgestaodeprojetosusandoodiagramaderedesparage renciarotempo Acesso em 16 jul 2017 207 Referências SILVA R M BELDERRAIN M C Considerações sobre o diagrama tornado em análise de sensibilidade Universidade do Vale do Paraíba São José dos Campos 2004 Disponível em httpwwwinicepgunivapbrcd INIC2004trabalhosinicpdfIC13Rpdf Acesso em 12 fev 2017 SIQUEIRA M C Gestão estratégica da informação como transformar o conteúdo informacional em conhecimento valioso Rio de Janeiro Brasport 2005 SOUSA E B D L Análise da gestão de escopo em gestão de projetos 2007 Monografia Bacharelado em Engenharia de Produção Universidade de São Paulo São Paulo 2007 SOUTO I S A importância da gestão de projetos em pequenas e médias empresas um estudo de caso na Eletro Pedro Ltda ParacatuMG 92 f 2011 Monografia Bacharelado em Administração Faculdade Tecsoma Paracatu 2011 SOUZA M S A Utilização da tecnologia da informação como ferra menta para atuar na gestão organizacional Artigo Bacharelado em Administração Geral Faculdade do Amapá Amapá 2009 TENÓRIO F G Gestão de ONGs principais funções gerenciais 9 ed Rio de Janeiro FGV 2005 Tecnologia da informação transformando as organizações e o trabalho Rio de Janeiro FGV 2007 TERRIBILI FILHO A Indicadores de gerenciamento de projetos moni toração continuada São Paulo M Books 2010 TOMIATTI T S Governança de TI 2012 40 f Monografia Tecnologia em Processamento de Dados Faculdade de Tecnologia de São Paulo São Paulo 2012 Disponível em httpwwwfatecspbrdtitcctcc00048pdf Acesso em 16 jan 2017 TRENTIM M H Manual do MSPROJECT 2010 e melhores práticas do PMI São Paulo Atlas 2012 TV ESCOLA Cardápio de projetos Boletim Salto para o Futuro out 2002 Disponível em httpcdnbitvescolaorgbrresourcesVMSResources Gerência de Projetos em TI 208 contentsdocumentpublicationsSeries130556CardapiodeProjetospdf Acesso em 26 jul 2017 VARGAS R V Manual prático do plano de projeto utilizando o PMBOK Guide 3 ed Rio de Janeiro Brasport 2007 VAZ L et al O PMO e as estruturas organizacionais 16 abr 2012 Disponível em httpwwwleandrovazprobropmoeasestruturasorga nizacionais Acesso em 10 jul 2017 VIANA I M Gerenciamento de projetos produtividade e eficiência na engenharia civil maio 2016 Disponível em httpscivilizacaoengenheira wordpresscom20160519gerenciamentodeprojetosprodutividadeeefi ciencianaengenhariacivil Acesso em 10 jul 2017 VILLELA C D S S Mapeamento de processos como ferramenta de rees truturação e aprendizado organizaciona Universidade Federal De Santa Catarina Florianópolis 2000 Disponível em httpsrepositorioufscbr handle12345678978638 Acesso em 29 jun 2017 GERÊNCIA DE PROJETOS EM TI Luiz Fernando Corcini Tecnologia GERÊNCIA DE PROJETOS EM TI Luiz Fernando Corcini O conceito de gestão tem evoluído muito ao longo do último século e embora não seja possível encontrar uma definição universalmente aceita existe algum consenso quanto ao fato de que a gerência de projetos deve incluir obrigato riamente um conjunto de tarefas que procurem garantir a utilização eficaz de todos os recursos disponibilizados pela organização a fim de serem atingidos os objetivos determinados Tendo em vista o contexto e as especificidades da TI neste livro tratamos da gerência de projetos nessa área sua abrangência e funcionamento nas organizações Fundação Biblioteca Nacional ISBN 9788538762973 9 788538 762973 CAPAGerência de Projetos em TIindd 1 01082017 105038