1 UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE CIÊNCIAS SOCIAIS APLICADAS MESTRADO PROFISSIONAL EM GESTÃO PÚBLICA RODRIGO XAVIER FERREIRA DE OLIVEIRA METODOLOGIA PARA GERENCIAMENTO DE PROJETOS EM TECNOLOGIA DA INFORMAÇÃO BASEADA NO GUIA PMBOK: um estudo de caso na Secretaria de Estado da Saúde Pública do Rio Grande do Norte NATAL Agosto/2014 2 RODRIGO XAVIER FERREIRA DE OLIVEIRA METODOLOGIA PARA GERENCIAMENTO DE PROJETOS EM TECNOLOGIA DA INFORMAÇÃO BASEADA NO GUIA PMBOK: um estudo de caso na Secretaria de Estado da Saúde Pública do Rio Grande do Norte Projeto de intervenção apresentado ao Programa de Pós Graduação em Gestão Pública da Universidade Federal do Rio Grande do Norte, em cumprimento às exigências para obtenção do grau de Mestre em Gestão Pública. Linha de pesquisa: Gerenciamento de Projetos em TI Orientadora: Profa. Dra. Anatalia Saraiva Martins Ramos. NATAL Agosto/2014 3 RODRIGO XAVIER FERREIRA DE OLIVEIRA METODOLOGIA PARA GERENCIAMENTO DE PROJETOS EM TECNOLOGIA DA INFORMAÇÃO BASEADA NO GUIA PMBOK: um estudo de caso na Secretaria de Estado da Saúde Pública do Rio Grande do Norte COMISSÃO EXAMINADORA _______________________________________________ Profa. Anatália Saraiva Martins Ramos, D. Sc. Orientadora _______________________________________________ Prof. Manoel Veras de Sousa Neto, D. Sc. Universidade Federal do Rio Grande do Norte - UFRN _______________________________________________ Prof. Antônio Sérgio Fernandes, D. Sc. Universidade Federal da Bahia - UFBA Natal, 12 de Agosto de 2014. 4 RESUMO Nos dias atuais a busca pelo crescimento faz com que as organizações procurem diferenciais competitivos, a gerência de projetos compartilha deste objetivo, por meio de técnicas que auxiliam na busca por uma melhora no gerenciamento das várias áreas de conhecimento através de uma metodologia de projetos. O mundo é movido por projetos e a busca por formas que melhor gerenciem as atividades como tempo, custo e prazo em prol do sucesso de um determinado projeto é algo constante. Uma das principais contribuições que a TI pode dar ao setor da saúde é o suporte para a área da gestão. A TI pode integrar processos, otimizar a interligação entre os diversos setores, fazer com que os hospitais tenham acesso a informações privilegiadas de boa qualidade, além do suporte na área assistencial, compartilhando imagens, unindo os aspectos ligados à enfermagem e serviço de nutrição. O grande desafio enfrentado pelo setor de Tecnologia da Informação da SESAP na atualidade está na gerência de projetos em TI, que por não existir faz com que investimentos na área sejam cada vez mais difíceis devido à esta deficiência na gestão de desenvolvimento de sistemas próprios sem custo adicional ao Estado. Este estudo busca criar e solidificar o Gerenciamento de Projetos no âmbito da Secretaria Estadual de Saúde através da implantação de um escritório de projetos que será responsável por gerir a metodologia final fruto deste trabalho, baseada no guia PMBOK, e ainda mostrar a funcionalidade aplicada ao desenvolvimento do Sistema Gestor Hospitalar estadual que será posteriormente instalado em todas as Unidades Regionais de Saúde e propondo medidas para a sustentabilidade e desenvolvimento do setor em meio às dificuldades do serviço público atual. Tal intervenção resultará em uma economia de mais de R$ 107.000,00 (cento e sete mil reais) referentes à gastos com softwares privados atualmente utilizados através de licenças de cessão de uso investidos pelo Estado do Rio Grande do Norte, o que representa mais de 5% do orçamento total da Secretaria de Estado da Saúde Pública do RN. 5 ABSTRACT Nowadays the search for growth makes organizations seeking competitive advantages, project management shares this goal, through techniques that assist in the search for an improved management of the various fields of knowledge through a design methodology. The world is driven by projects and the search for ways to better manage activities such as time, cost and term towards the success of a particular project is something constant. A major contribution that IT can make to the health sector is the support for the management area. IT can integrate processes, optimize the interconnection between the various sectors, make hospitals have access to inside information of good quality, as well as support in the healthcare area, sharing pictures, uniting the various aspects of nursing and nursing service. The major challenge faced by the SESAP Information Technology sector at present is in project management in IT , which does not exist makes investments in the area are increasingly difficult due to this deficiency in management develop their own systems without cost additional to the State. This study seeks to build and strengthen the Project Management within the Department of Health through the implementation of a project office that will manage the final result of this work methodology based on PMBOK, and still show the functionality applied to development the state Hospital Management System that will later be installed on all Regional Health Units and proposing measures for the sustainability and development of the sector amid the difficulties of the current public service. Such action will result in a savings of more than R$ 107,000.00 (one hundred seven thousand) regarding spending private software currently used by the assignment of invested by the State of Rio Grande do Norte user licenses, representing more than 5 % of the total budget of the State Department of Public Health of the State. 6 AGRADECIMENTOS A princípio, agradeço a Deus, pela força e coragem durante toda esta longa caminhada, A minha querida esposa Silvanete, que de forma especial e carinhosa me deu força e coragem, me apoiando nos momentos de maiores dificuldades; Ao meu amável filho Miguel, mais recente e profunda motivação para a conclusão deste trabalho, Aos meus pais e irmãos, minhas fontes inesgotáveis de carinho e de apoio incondicional, A todos os amigos e familiares pelo apoio e por compreenderem minha ausência, A minha sempre adorável orientadora Anatália, por ter sido, além de orientadora e professora, uma grande amiga e incentivadora durante esses difíceis e longos anos de trabalho e estudo, A todos os professores da UFRN, pelos ensinamentos; Aos funcionários da UFRN por toda a ajuda; A Ricardo Lima, Terezinha Rêgo e Carlos Pinto, gestores e chefes imediatos, pela flexibilização dos horários de trabalho que me permitiu concluir este trabalho; E por fim, agradeço aos meus inesquecíveis parceiros e companheiros da SESAP nesta empreitada, em especial George Carvalho, Sérgio Alexandre e Denise Wingerter pela colaboração, apoio e companheirismo inquestionável. 7 LISTA DE TABELAS Tabela 01: Classificação de Projetos de Acordo com Passos 45 Tabela 02: Responsabilidade x Participação segundo VERZUH (2005) 49 Tabela 03: Responsabilidade dos EP's. 51 Tabela 04: Processos utilizados (negrito) na metodologia do PMBOK 2013 64 Tabela 05: Processos contidos na iniciação: entradas, saídas e ferramentas 67 Tabela 06: Processos contidos no planejamento: entradas, saídas e ferramentas 73 Tabela 07: Matriz de Responsabilidades do Projeto 97 Tabela 08: Processos contidos na execução: entradas, saídas e ferramentas 103 Tabela 09: Processos contidos no monitoramento: entradas, saídas e ferramentas 109 Tabela 10: Processos contidos no encerramento: entradas, saídas e ferramentas 113 8 LISTA DE IMAGENS Figura 01: Constituição numérica PMBOK 2013 32 Figura 02: Interação entre grupos de processos de gerenciamento de projetos 34 Figura 03: Processos de gerenciamento da integração distribuídos ao longo das fases 35 Figura 04: Relacionamentos Lógicos do MDP 38 Figura 05: Relações entre os Stakeholders e o Projeto (PMBOK 2013) 43 Figura 06: Interação entre grupos de processos de gerenciamento de projetos 44 Figura 07: Escritório Corporativo de Projetos 52 Figura 08: Escritório Divisional de Projetos 52 Figura 09: Escritório Setorial de Projetos 53 Figura 10: Escritório Departamental de Projeto 53 Figura 11: Organograma da SESAP 58 Figura 12: Regionalização e Unidades regionais de saúde (URSAP´s) 59 Figura 13: Subdivisão da Informática SESAP/RN 60 Figura 14: O ciclo de vida do projeto subdividido em fases ou grupos de processos 63 Figura 15: Processos da fase de iniciação inicialmente proposta 66 Figura 16: Metodologia Final Proposta – Fase de Iniciação. 71 Figura 17: Processos da fase de planejamento inicialmente proposta 72 Figura 18: Estrutura Analítica do Projeto 84 Figura 19: Fluxograma para Controle de Mudanças no Escopo 85 Figura 20: Fluxograma para Controle de Mudanças de Riscos 87 Figura 21: Probabilidade x Gravidade de Riscos 88 Figura 22: Cronograma do projeto-piloto “Módulo PMO e Base de Dados” 91 Figura 23: Fluxograma para Controle de Mudanças de Prazos 92 Figura 24: Fluxograma para Controle de Mudanças da Qualidade 99 Figura 25: Metodologia Final Proposta – Fase de Planejamento 101 Figura 26: Processos da fase de execução inicialmente proposta 102 Figura 27: Metodologia Final Proposta – Fase de Execução 107 Figura 28: Processos da fase de monitoramento e controle inicialmente proposta 108 Figura 29: Metodologia Final Proposta – Fase de Monitoramento e Controle 111 Figura 30: Processos da fase de encerramento inicialmente proposta 112 Figura 31: Metodologia Final Proposta – Fase de Encerramento 114 9 LISTA DE SIGLAS SESAP – Secretaria de Estado da Saúde Pública do Rio Grande do Norte SUININ – Suibcoordenadoria de Informação e Informática COAD – Coordenadoria Administrativa COTIN – Coordenadoria de Tecnologia da Informação CPCS – Coordenadoria de Planejamento e Controle de Serviços de Saúde CRH – Coordenadoria de Recursos Humanos CPS – Coordenadoria de Promoção à Saúde COHUR – Coordenadoria de Operações Hospitalares e Unidades de Referência COF – Coordenadoria de Orçamento e Finanças URSAP – Unidade Regional de Saúde Pública SIGUS – Sistema Integrado de Gerenciamento de Usuários do SUS ABNT – Associação Brasileira de Normas Técnicas ISO – International Organization for Standardization NBR – Norma Brasileira PMBOK – Project Management Body of Knowledge GP – Gerente de Projetos COBIT – Control Objectives for Information and Related Technologies ITIL – Information Technology Infrastructure Library PMI – Project Management Institute PMP – Project Management Professional EAP – Estrutura Analítica do Projeto WBS – Work Breakdown Structure RBS – Risk Breakdown Structure TAP – Termo de Abertura do Projeto CPM – Método do Caminho Crítico EP/EGP – Escritório de Projetos TI – Tecnologia da Informação TCE – Tribunal de Contas do Estado CE – Center of Excellence PMO – Project Management Office PrgMO – Program Management Office APO – Accountable Project Office APT – Authonomous Project Team PSO – Project Support Office PMCOE – Project Management Center of Excellence CPO – Chief Project Office PERT – Program Evaluation Review Technique PGP – Plano de Gerenciamento do Projeto PGC – Plano de Gerenciamento de Custos PGCO – Plano de Gerenciamento das Comunicações PGPI – Plano de Gerenciamento das Partes Interessadas PGE – Plano de Gerenciamento do Escopo PGR – Plano de Gerenciamento de Riscos PGA – Plano de Gerenciamento das Aquisições PGT – Plano de Gerenciamento de Tempo PGRH – Plano de Gerenciamento de Recursos Humanos PGQ – Plano de Gerenciamento da Qualidade 10 FUNASA – Fundação Nacional de Saúde SINASC – Sistema de Informações sobre Nascidos Vivos SIM – Sistema de Informações sobre Mortalidade SINAN – Sistema de Informação de Agravos de Notificação HOSPUB – Sistema Integrado de Informatização de Ambiente Hospitalar SSAME – Sistema de Gerenciamento de Arquivo Médico; SIGHO – Sistema de Gerenciamento de Internação e Alta; SIGUE – Sistema de Gerenciamento de Unidades de Emergência; SIADT – Sistema de Apoio à Diagnose e Terapia; SICEC – Sistema de Gerenciamento de Centro Cirúrgico; SINAT – Sistema de Gerenciamento Perinatal (Aguardando Homologação); SIGAE – Sistema de Gerenciamento de Unidades Ambulatoriais Especializadas SUS – Sistema Único de Saúde DATASUS – Departamento de Informática do SUS DATAPREV – Empresa de Tecnologia e Informações da Previdência Social IIS – Informação e Informática em Saúde 11 SUMÁRIO 1. INTRODUÇÃO 13 1.1. Problema de Pesquisa 13 1.2. Objetivo Geral 15 1.3. Objetivos Específicos 16 1.4. Justificativa 16 2. REFERENCIAL TEÓRICO 19 2.1. Políticas Públicas de Saúde Voltadas para a TI 19 2.1.1. Contexto da Política e Gestão da Saúde no Brasil 19 2.1.2. A Importância da TI na Saúde 24 2.2. Gerenciamento de Projetos 25 2.2.1. O Gerente de Projetos 27 2.2.2. Gerenciamento de Projetos e a sua Importância 28 2.2.3. Project Management Institute - PMI 29 2.2.4. PMBOK: Guia de Conhecimento em Gerencia de Projetos 31 2.2.4.1. A história do Guia PMBOK 31 2.2.4.2. Grupos de processos da GP no Guia PMBOK 33 2.2.4.3. Áreas de Conhecimento do Guia PMBOK 34 2.2.4.3.1. Gerenciamento da integração 35 2.2.4.3.2. Gerenciamento do escopo 36 2.2.4.3.3. Gerenciamento de tempo 36 2.2.4.3.4. Gerenciamento de custos 39 2.2.4.3.5. Gerenciamento da qualidade 39 2.2.4.3.6. Gerenciamento dos recursos humanos 40 2.2.4.3.7. Gerenciamento das comunicações 40 2.2.4.3.8. Gerenciamento de riscos 41 2.2.4.3.9. Gerenciamento das aquisições 42 2.2.4.3.10. Gerenciamento das partes interessadas 42 2.2.4.4. Grupos de processos e suas áreas de atuação 43 2.2.4.5. Classificação e Complexidade de Projetos 44 2.2.4.6. Escritório de Projetos 47 2.2.4.6.1. Importância da Posição do Escritório de Projetos Na Organização 51 3. PROCEDIMENTOS DE PESQUISA 56 3.1. TIPOLOGIA 56 4. INSTITUIÇÃO 58 4.1. A Secretaria de Estado da Saúde Pública do RN 58 4.2. Estrutura Organizacional da SUININ 60 5. MODELO ATUAL 60 6. MODELO PROPOSTO 62 7. DESENVOLVIMENTO 63 7.1. Aplicação e Ciclo de Vida do Projeto 63 7.1.1. Iniciação 65 7.1.1.1. Proposta Inicial 65 12 7.1.1.2. Aplicação e Proposta Final 66 7.1.2. Planejamento 71 7.1.2.1. Proposta Inicial 71 7.1.2.2. Aplicação e Proposta Final 73 7.1.2.2.1. Plano de Gerenciamento do Projeto 76 7.1.2.2.2. Plano de Gerenciamento das Partes Interessadas 77 7.1.2.2.3. Plano de Gerenciamento das Comunicações 79 7.1.2.2.4. Definindo o Escopo do Projeto 81 7.1.2.2.5. Definindo a Estrutura Analítica do Projeto 82 7.1.2.2.6. Plano de Gerenciamento do Escopo 84 7.1.2.2.7. Plano de Gerenciamento dos Riscos 86 7.1.2.2.8. Plano de Gerenciamento das Aquisições 89 7.1.2.2.9. Plano de Gerenciamento de Tempo 91 7.1.2.2.10. Plano de Gerenciamento de Custos 94 7.1.2.2.11. Plano de Gerenciamento de Recursos Humanos 96 7.1.2.2.12. Plano de Gerenciamento da Qualidade 98 7.1.2.2.13. Definindo o Orçamento 100 7.1.3. Execução 101 7.1.3.1. Proposta Inicial 101 7.1.3.2. Aplicação e Proposta Final 103 7.1.4. Monitoramento e Controle 107 7.1.4.1. Proposta Inicial 107 7.1.4.2. Aplicação e Proposta Final 108 7.1.5. Encerramento 112 7.1.5.1. Proposta Inicial 112 7.1.5.2. Aplicação e Proposta Final 113 8. AVALIAÇÃO DE RESULTADOS 115 8.1. Considerações Finais 117 REFERÊNCIAS 119 APÊNDICES 123 ANEXOS 182 13 1. INTRODUÇÃO De acordo com GUEDES E SAMBO (2010, p.12), os investimentos em tecnologia de informação (TI) no setor de saúde alcançaram os US$ 80 bilhões em 2010, dos quais US$ 5 bilhões só na América Latina. Os números mostram o que os gestores das maiores instituições de saúde do Brasil já perceberam: a tecnologia pode e vem sendo usada em todo o mundo a favor da melhoria da assistência e dos cuidados em saúde e pode beneficiar a gestão como um todo. O desenvolvimento de parcerias, soluções e inovações para segurança eletrônica, controle de acesso, redes, comunicação, entre outros, torna-se uma prática em hospitais, clínicas e laboratórios, e as empresas de tecnologia ampliam cada vez mais a oferta de produtos e serviços para o setor. O objetivo é a garantia de um bom atendimento, cada vez mais integrado, ágil, humanizado e ambientalmente sustentável. Uma das principais contribuições que a TI pode dar ao setor é suporte para a área da gestão. A TI pode integrar processos, otimizar a interligação entre os diversos setores, fazer com que os hospitais tenham acesso a informações privilegiadas de boa qualidade, além do suporte na área assistencial, compartilhando imagens, unindo os aspectos ligados à enfermagem e serviço de nutrição. Nos dias atuais a busca pelo crescimento faz com que as organizações procurem diferenciais competitivos, a gerência de projetos compartilha deste objetivo, por meio de técnicas que auxiliam na busca por uma melhora no gerenciamento das várias áreas de conhecimento através de uma metodologia de projetos. O mundo é movido por projetos e a busca por formas que melhor gerenciem as atividades como tempo, custo e prazo em prol do sucesso de um determinado projeto é algo constante. A falta de interesse em aplicar uma metodologia de gerenciamento que melhor se adapte a situação da organização pode acarretar problemas e custos muitas vezes catastróficos e com relação à Saúde Pública, isto deve ser tratado com cuidado redobrado. 1.1 PROBLEMA DE PESQUISA Atualmente o DATASUS, órgão da Secretaria de Gestão Estratégica e Participativa do Ministério da Saúde que gere a informática no SUS, conta com um sistema “livre” para uso porém com licenças paralelas para utilização, suporte e garantia do banco de 14 dados que é prioritário, além do sistema ser extremamente defasado tecnologicamente, o que dificulta a utilização tanto por gestores quanto por profissionais que resistem à qualquer mudança quando se trata de operacionalização, monitoramento e controle. O sistema em questão, denominado HOSPUB, não encontra-se em utilização justamente pela sua limitação com relação à cobertura das necessidades hospitalares, módulos incompletos e interface desagradável são apenas algumas das características do sistema. Por tudo isto disposto, a Secretaria de Estado da Saúde Pública do RN (SESAP- RN) conta hoje com um sistema produzido por uma empresa terceirizada que custa aos cofres públicos mais de 1 milhão de reais por ano desconsiderando multas e juros por atraso de pagamentos e aditivos contratuais geralmente contratados ao longo do ano. O sistema em questão é incompleto e seu custo é baseado na quantidade de instâncias instaladas, ou seja, quantidade de hospitais que se utilizam dos serviços, atualmente apenas o Hospital Pediátrico Maria Alice Fernandes tem cobertura satisfatória de suporte e sistema por ter sido o pioneiro na implantação do sistema houve um “termo de doação” apenas pra aquela unidade, em recente auditoria operacional realizada pelo Tribunal de Contas do Estado do Rio Grande do Norte, um perfil sobre esta “doação” foi traçado e foram identificados problemas críticos como citado anteriormente, a não contemplação de todas as unidades hospitalares, a impossibilidade do efetivo controle da SESAP sobre o sistema e sobre os dados gerados pelas unidades, a utilização induzida de inexigibilidades de licitação, já que apenas a empresa em questão pode efetuar a implantação, instalação, manutenção, treinamento e suporte além de fomentar a dependência da SESAP em relação à empresa visto que a SESAP não possui acesso administrativo ao sistema. O Hospital Monsenhor Walfredo Gurgel/ Clovis Sarinho conta com alguns módulos instalados mas com suporte crítico devido à constante atrasos nos pagamentos à empresa responsável, o Estado conta com aproximadamente 27 unidades de saúde que necessitam de sistemas de informação. O grande desafio enfrentado pelo setor de Tecnologia da Informação da SESAP na atualidade está na inexistência da gerência de projetos em TI, fazendo com que investimentos no mesmo sejam cada vez mais escassos devido à falta de projetos para desenvolvimento de sistemas próprios. Alguns autores defendem a ideia de que um sistema baseado na sua complexidade deve fazer parte de um projeto a ser gerenciado de perto por um profissional exclusivamente destinado para o aumento da probabilidade de sucesso na execução da implementação, outro autores preferem mostrar a importância do gerenciamento de projetos independente da complexidade da tarefa a ser executada. Em julho de 2012 o Tribunal de Contas do Estado expediu um documento recomendando à Secretaria de Saúde 82 15 providências a serem tomadas com relação à melhoras tanto nos serviços prestados à população quanto na correção de seu modelo de gestão, dentre as recomendações algumas são relacionadas à TI e à falta de gerenciamento de projetos no órgão: “61) considerar outras formas de aquisição de sistemas, como a utilização de softwares gratuitos, convênios com outros estados, desenvolvimento de sistema próprio e até mesmo a compra de um sistema (item 431 do relatório final de auditoria); 62) rever o processo de implantação, instalação, treinamento e suporte do sistema de gestão hospitalar (SALUX), utilizando técnicas de gerenciamento de projetos, de forma a reduzir os riscos de insucesso na implantação e manutenção. (item 448 do relatório final de auditoria) “ Considerando o anteposto e a atual situação organizacional, este estudo busca criar e solidificar o Gerenciamento de Projetos no âmbito da Secretaria Estadual de Saúde através da implantação de um escritório de projetos que será responsável por gerir a metodologia final fruto deste trabalho, baseada no guia PMBOK, mostrando a funcionalidade do modelo aplicada no desenvolvimento do Sistema Gestor Hospitalar estadual que será posteriormente instalado em todas as Unidades Regionais de Saúde e propondo medidas para a sustentabilidade e desenvolvimento do setor em meio às dificuldades do serviço público atual. A questão a ser respondida é então de natureza científica e ordem prática: De que forma a implantação de uma metodologia de gerenciamento de projetos para o desenvolvimento de sistemas de informação no âmbito da SESAP/RN ajuda na solução de problemas de ordem organizacional do setor? 1.2 OBJETIVO GERAL O objetivo deste trabalho é desenvolver uma metodologia “padrão” para gerenciamento de projetos em tecnologia da informação baseado no perfil atual da Secretaria de Estado da Saúde Pública do RN baseada nos conceitos do Project Management Body of Knowledge - PMBOK (Guia de conhecimento em gerência de projetos), em especial no desenvolvimento do Sistema Gestor Hospitalar que será implantado em toda rede hospitalar no âmbito do Rio Grande do Norte. 16 1.3 OBJETIVOS ESPECÍFICOS O presente trabalho será realizado em etapas, as quais corresponderão aos objetivos a serem alcançados, conforme segue: a) Definir e caracterizar as necessidades da SESAP/RN dentro da gestão de projetos em TI considerando a situação atual com relação a todos os recursos disponíveis; b) Identificar os processos fundamentais para compor uma metodologia inicial e escalável; c) Definir o escopo do projeto, focando o cumprimento de prazos, custo e qualidade; d) Projetar o sequenciamento das atividades identificando e mitigando o caminho crítico do projeto; e) Desenvolver o Plano de Gerenciamento baseado na metodologia desenvolvida e, enfim, experimentar a viabilidade prática do projeto; 1.4 JUSTIFICATIVA Segundo PORTER (2001), a internet é um conjunto poderoso de ferramentas que podem ser utilizadas em praticamente todas as indústrias e como parte de praticamente qualquer estratégia. LOSHIN (2003) dizia que nos últimos anos a habilidade para criar, coletar e armazenar informação ultrapassou a nossa capacidade de fazer uso significativo destas informações. Especificamente na área da saúde, com informações sobre ocupação de leitos, disponibilidade de medicamentos, plantões de profissionais atualizados em uma base de dados, com a utilização de ferramentas de B.I., por exemplo, é possível prever um problema maior com meses de antecedência e procurar evitá-lo tomando decisões estratégicas relacionadas ao problema em questão que seria corretamente medido quantitativa e qualitativamente de acordo com o histórico contido em um Data Warehouse. Essa crescente inundação de informações dificulta o processo de tomada de decisão, na medida em que a alta e média gerência se sentem impotentes no processo de busca e recuperação de informações (BARBIERI, 2001). Para que todo esse processo de manipulação de dados possa ser realizado, sistemas de informação devem dar subsídio alimentando bases de dados muitas vezes gigantescas que posteriormente servirão de “mina” para que ferramentas específicas façam o 17 trabalho de transformação desses dados em informações úteis para tomada de decisão. O grande problema é que muitas vezes esses sistemas são extremamente gigantescos e seus valores estão fora da realidade de muitos estados e municípios, assim para haver um controle satisfatório no desenvolvimento de uma aplicação tão imensa faz-se necessário um Gerenciamento de Projeto específico para esta meta considerando uma metodologia própria desenvolvida com base nos ativos de processos organizacionais encontrados no âmbito da execução. Em situação semelhante, CINTRA (2007) desenvolveu um trabalho de intervenção junto à prefeitura de Dourados/MS que pretendia executar um processo de implantação da gestão de projetos através da Secretaria Municipal de Planejamento e Meio Ambiente, responsável pela implantação e definição de uma metodologia mista, modelo de gestão implantada no Estado de Mato Grosso do Sul e adaptado à realidade do município, concomitante com contratação de consultoria externa. A implantação se iniciou em 2004 e até 2005 ainda não estava solidificada, ao final de 2007 o autor considerou que as ações foram implantadas de maneira satisfatória. Em recente perfil traçado pelo TCE/RN através de relatório de auditoria operacional realizado em 2013 foi enfatizado o desconhecimento dos gestores da importância da TI, inviabilizando a informatização de toda a rede hospitalar, inviabilizando, inclusive, a criação de uma central de regulação informatizada. Desta forma, ocorre o comprometimento da informatização das unidades hospitalares, deficiências no atendimento das demandas e na oferta de serviços e, principalmente, contribui para a completa dependência de empresas terceirizadas. O mesmo relatório destacou a posição da SUININ na estrutura organizacional citando algumas causas para a ausência de processos, procedimentos e papéis encontrada no órgão: o mau posicionamento da TI dentro da organização, na falta de um planejamento da TI e na carência de recursos humanos especializados. Sem um posicionamento, um planejamento e especialistas na área, as atividades da TI acabam tornando-se reativas e inconsistentes, já que esta só se envolve nos estágios finais dos projetos de negócio não possuindo uma participação efetiva na elaboração dos mesmos. Ao final o TCE/RN classifica a situação caótica encontrada na TI da SESAP e cita as causas gerais para esta situação como a ausência de planejamento estratégico de TI, deficiência de recursos humanos especializados, ausência de políticas, procedimentos e planos de TI; especificamente, citando a ausência de inventário de ativos, de projetos de implantação e manutenção da infraestrutura e em seguida recomendando que sejam utilizadas técnicas de gerenciamento de projetos de forma a atingir os objetivos propostos dentro de parâmetros de 18 qualidade determinados, obedecendo a um planejamento prévio de prazos e custos, esperando desta maneira, diminuir os riscos relacionados à implantação do complexo regulatório, melhorando o atendimento hospitalar e utilizando os recursos de forma mais eficiente. Outra recomendação importante diz respeito às normas internacionais e padrões de qualidade à serem usados como base para um melhor gerenciamento tanto de projetos quanto de processos quando recomenda estabelecer papéis e funções, definição de planos, políticas e procedimentos técnicos na área de TI e, que estes sejam formalmente aprovados e comunicados a toda organização. Recomenda, ainda, que estas políticas sigam as normas e as boas práticas internacionais, especialmente COBIT 4.1, ITIL V3, PMBOK e que sigam as orientações constantes nos diversos acórdãos do TCU. O conjunto de práticas citado, PMBOK, é um padrão que pode ser usado para orientar o desenvolvimento da metodologia de gerenciamento de projetos da organização, mas não pode ser a metodologia em si. Seria praticamente impossível e completamente inviável implementar o PMBOK como ele é, em uma organização, contudo pode-se desenvolver uma metodologia real para uma organização tomando como base o PMBOK para tal. Devido ao perfil atual da SESAP e a forma com que são conduzidas tanto contratações como aquisições e a instável composição do quadro de servidores foi decidido utilizar essa base de conhecimento para desenvolver uma metodologia própria para a SESAP baseada nos seus ativos processuais organizacionais para então usar a metodologia para gestão de projetos em desenvolvimento de software na SUININ, buscando a aplicação em um sistema gestor hospitalar como recomendado pelo TCE/RN. A metodologia precisa mostrar claramente o ciclo de vida do projeto na organização, e não os grupos de processos de gerenciamento de projetos, tornando-o assim um guia para o gerente de projeto seguir. Ela deve mostrar critérios claros de entrada e saída para cada fase do ciclo de vida do projeto, assim como deve responder às questões de como o início do projeto, planejamento, execução, controle e encerramento se darão ao nível de projeto e de fase. Outra parte importante a ser considerada é que a metodologia desenvolvida deve considerar temas-chave do gerenciamento de projetos, como processos iterativos, elaboração progressiva, lições aprendidas, melhoria contínua, ética e conduta profissional, etc. Uma das principais qualidades da metodologia: ela deve ser aplicável, e não sobrecarregar os gerentes de projetos com documentos enormes que eles tem de ler e interpretar para serem capazes de gerenciar um projeto. Nesse caso, muitos gerentes de projeto não vão ler, e cada um vai interpretar os processos de forma diferente, usando a 19 tecnologia para tornar a metodologia mais acessível e amigável a fim de tornar as ferramentas, técnicas e modelos, partes essenciais a serem utilizadas na execução dos processos. No decorrer do desenvolvimento da metodologia, o maior foco será o cumprimento dos prazos, escopo, custo e qualidade, visando aumentar as chances de sucesso dos projetos e diminuir os riscos, serão demonstradas fases e seus devidos processos, desenvolvidos diagramas, gráficos e planilhas que auxiliarão na tomada de decisão estratégica com relação ao cronograma do projeto. Não menos importante, deve-se certificar de que o processo é escalável e pode ser desenvolvido, levar em consideração os atuais níveis de maturidade, e buscar novos níveis em uma prática gradual com estágios de aperfeiçoamento programáveis. As organizações atuais tem um grande desafio que são as frequentes mudanças e adaptações para a demanda do mercado moderno, onde os prazos, custos e qualidade são fatores determinantes e, segundo CLELAND e IRELAND (2000), a gerência de projetos é o principal meio para lidar com mudanças de produtos, de serviços e de processos nas organizações contemporâneas. Levando em consideração a importância de um gerenciamento de projetos eficiente e eficaz o presente trabalho realiza uma análise da metodologia em gerência de projetos, baseada no PMBOK (Project Management Body of Knowledge), com o objetivo de implantar os processos de iniciação, planejamento, execução, planejamento e controle e encerramento em projetos de desenvolvimento de software, efetivando o PMO (Project Management Office) no âmbito da SESAP/RN. 2. REFERENCIAL TEÓRICO 2.1 POLÍTICAS PÚBLICAS DE SAÚDE VOLTADAS PARA A T.I. 2.1.1 Contexto da Política e Gestão de Saúde no Brasil Como exposto por CANOTILHO (2007), ao contrário do meio ambiente, a saúde, como valor próprio e separado do núcleo-mãe ‘vida’, foi formalmente tratada, sob vários enfoques, pelas constituições anteriores à de 1988. O direito fundamental à saúde, como direito de todos, ressalvado na Constituição brasileira de 1988 foi efetivado e regulamentado pela lei 8.080/90, conhecida por Lei do Sistema Único de Saúde (SUS) que conceitua o SUS como um conjunto de ações e serviços de saúde, prestados por órgãos e instituições públicas 20 federais, estaduais e municipais, da administração direta e indireta e das fundações mantidas pelo poder público. Antes desta regulamentação do disposto constitucional pela Lei do SUS, suas ações para a recuperação da saúde e assistência médica eram prestadas pelo Ministério da Saúde, criado pela Lei 1.920/53. “As políticas públicas voltadas para a saúde nos últimos tempos têm sido de grande importância para a população de todo o país, mesmo sabendo-se que a sua implementação não tenha sido aplicada de forma eqüitativa e satisfatória. Historicamente, as políticas públicas e especialmente no Brasil vêm se caracterizando de forma subordinada aos interesses econômicos e políticos, sendo implementadas através de práticas assistencialistas e clientelistas, refletindo relações que não incorporam o reconhecimento dos direitos sociais.” SILVA(2009). Segundo SILVA (2009), constata-se a existência de um padrão de relações que fragmenta e desorganiza a classe subalterna ao apresentar como favor os direitos do cidadão. Percebe-se ainda o crescimento da dependência de segmentos cada vez maiores da população, no que concerne à intervenção estatal, por não dispor de meios para satisfação de suas necessidades cotidianas. “Mesmo após a Constituição de 1988, que instituiu Sistema Único de Saúde, o perfil da organização de programas e serviços de saúde ainda apresenta-se caracterizado pela centralização, pelo governo federal, de diretrizes e prioridade para o setor de saúde destinadas às esferas estadual e municipal. Por outro lado, a acentuada privatização define o investimento no setor de saúde com recursos do orçamento da união produzidos pelo setor privado, visualizadas em nossa realidade principalmente através do fortalecimento dos planos de saúde.” SILVA(2009). Nesse sentido, constata-se que o conjunto de ações destinadas aos Estados e municípios distancia-se das reais condições de saúde vivenciadas pela população brasileira. Como consequência, a população usuária recebe uma prestação de serviços cuja lógica de acesso não corresponde à relação: disponibilidade tecnológica/necessidade de atendimento, mas a exigência de lucratividade do setor privado (SILVA, 2009). Moraes e Vasconcellos consideram que as tecnologias que envolvem a “informação e informática em saúde” (IIS) – campo temático de crescente desenvolvimento e importância nas sociedades contemporâneas – não vem sendo incorporadas no setor de saúde no Brasil com a mesma velocidade e dinamismo, quando se analisa a implementação do Sistema Único de Saúde (SUS) e sua pouca “apropriação” por parte dos gestores, profissionais, Conselhos de Saúde, população e instituições de ensino e pesquisa, constituindo um dos limitantes na definição de políticas adequadas para a melhoria das condições de saúde da população. Toda essa lógica incide diretamente em todos os segmentos da sociedade que necessitam dos serviços públicos como: crianças, adolescentes, deficientes e, 21 consequentemente, os idosos, que se encontram cada vez mais numa situação de desamparo, perda de status, de segregação social, de marginalidade. Ainda segundo Moraes e Vasconcellos, “na dinâmica do estabelecimento de uma escala de prioridades a informação exerce um papel estratégico. Intrínseca ao próprio processo decisório, a informação instrumentaliza a identificação do que se quer transformar. O valor da Informação é função do seu valor de uso nos processos de tomada de decisão”. A afirmação de Vasconcellos converge com a proposta apresentada no documento Política Nacional de Informação e Informática disponibilizado em março de 2004 pelo Ministério da Saúde/SE/Departamento de Informação e Informática do SUS que inclui algumas das deliberações da 12ª. Conferência Nacional de Saúde. Destacam-se, algumas diretrizes como o estabelecimento de mecanismos de compartilhamento de dados de interesse para a saúde e ampliação da produção e disseminação de informações de saúde de forma a atender tanto às necessidades de usuários, profissionais, gestores, prestadores de serviços e controle social, quanto ao intercâmbio com instituições de ensino e pesquisa, outros setores governamentais e da sociedade e instituições internacionais. Assim como a institucionalização de “mecanismos que garantam a participação de usuários e profissionais de saúde no processo de desenvolvimento de sistemas de informação em saúde para o SUS.” Assim sendo, evidencia-se que os espaços definidores da política de informação, na medida em que se observa a ampliação de seu significado estratégico nas sociedades contemporâneas, passam a ser objeto de interesse das instituições públicas e dos demais espaços de governo, em todos os níveis da sociedade. O DATASUS é o nome do departamento de informática do Sistema Único de Saúde do Brasil. Trata-se de um órgão da Secretaria de Gestão Estratégica e Participativa do Ministério da Saúde com a responsabilidade de coletar, processar e disseminar informações sobre saúde. É responsável, também, pelos sistemas e aplicativos necessários para registrar e processar as informações de saúde. Um exemplo é o Cadastro Nacional de Estabelecimentos de Saúde (CNES), que contém todas as informações sobre a base instalada para atendimento à população no país: equipamentos, leitos e os profissionais, por especialidade, com informações tanto do segmento privado conveniado ao SUS quanto do segmento público. Segundo o documento de Trajetória do DATASUS (2002), em 1991 ocorreu a criação do Departamento de Informática do SUS – DATASUS de forma concomitante com a criação da Fundação Nacional de Saúde – FUNASA que foi instituída pelo Decreto 100 de 1991, publicado e retificado no D.O.U. de abril daquele mesmo ano. O referido Decreto além 22 de regulamentar a transferência dos funcionários que iriam compor o quadro de servidores da FUNASA – oriundos da DATAPREV, Fundação SESP e SUCAM - retirou da DATAPREV a função específica de controle e processamento das contas referentes ao setor de Saúde, que passaram à responsabilidade do Ministério da Saúde, por delegação atribuída à Fundação Nacional de Saúde – FUNASA, através do seu Departamento de Informática. No início, o conjunto de serviços consistia basicamente dos sistemas de faturamento – ambulatorial e hospitalar – e dos sistemas de acompanhamento de “Nascidos Vivos” – SINASC -, “Agravos de Notificação” – SINAN – e de “Mortalidade” - SIM, além de pequenos sistemas voltados para gestão administrativa, tais como controle de materiais, de patrimônio e de processos. Com relação aos Sistemas de Gestão Hospitalar, no começo de 1992 surge a versão inicial dos sistemas voltados à gestão local de Unidades de Saúde. Surge o HOSPUB, na ocasião denominado Sistema de Gerenciamento Hospitalar - SIGHO e no final de 1992 a primeira versão do Sistema de Gerenciamento Ambulatorial - SIGAB. Em seguida foram desenvolvidos alguns sistemas solicitados pela FUNASA tais como: Sistema de Gerenciamento de Recursos Humanos - SISGRU, Sistema de Programas de Controle de Endemias, voltados para o gerenciamento das operações de campo e diversos aplicativos de cunho Administrativo e para o Controle de Imunização. No início de 1998, por determinação do Senhor Secretário Executivo, em virtude do grande distanciamento do DATASUS em relação ao Ministério da Saúde foi criado um grupo de trabalho para viabilizar sua transferência para a administração direta, no Ministério da Saúde dando-se ao DATASUS uma nova estrutura organizacional, com a ampliação do seu corpo gerencial para três Coordenações Gerais. São estas as competências definidas para o DATASUS pelo Decreto: I. fomentar, regulamentar e avaliar as ações de informatização do SUS, direcionadas para a manutenção e desenvolvimento do sistema de informações em saúde e dos sistemas internos de gestão do Ministério; II. desenvolver, pesquisar e incorporar tecnologias de informática que possibilitem a implementação de sistemas e a disseminação de informações necessárias às ações de saúde; III. definir padrões, diretrizes, normas e procedimentos para transferência de informações e contratação de bens e serviços de informática no âmbito dos órgãos e entidades do Ministério; IV. definir padrões para a captação e transferência de informações em saúde, visando à integração operacional das bases de dados e dos sistemas desenvolvidos e implantados no âmbito do SUS; V. manter o acervo das bases de dados necessárias ao sistema de informações em saúde e aos sistemas internos de gestão institucional; VI. assegurar aos gestores do SUS e órgãos congêneres o acesso aos serviços de informática e bases de dados, mantidos pelo Ministério; 23 VII. definir programas de cooperação técnica com entidades de pesquisa e ensino para prospecção e transferência de tecnologia e metodologias de informação e informática em saúde; VIII. apoiar Estados, Municípios e o Distrito Federal, na informatização das atividades do SUS; e IX. coordenar a implementação do sistema nacional de informação em saúde, nos termos da legislação vigente. Atualmente observa-se no DATASUS, de maneira geral, uma forma de atuar sob demandas isoladas, independentes e desvinculadas umas das outras, gerando sistemas de informação que não pressupõem uma perspectiva integradora. Resulta deste processo um cenário de fragmentação que dificulta a visibilidade e o “cruzamento” das informações contidas nos diversos sistemas de informação, criando obstáculos ou mesmo inviabilizando prospecções e análises de questões relativas à saúde da população. Estas condições de trabalho subtraem subsídios dos tomadores de decisão. Tal forma de atuação relaciona-se ao contexto histórico ao qual se vincula o DATASUS que, tendo como herança o modelo de gestão da DATAPREV, caracterizando-se por, uma lógica centralizadora e tecnocrata, como adjetiva Lima et al, modelo com o qual teve de lidar a implantação do projeto da Reforma Sanitária. Reflexos deste processo se fazem sentir na política de TIS, que além de restringirem subsídios aos tomadores de decisão, restringem também a visibilidade dos processos informacionais podendo comprometer a transparência de sua atuação. Cabe lembrar a afirmação de JARDIM (2008) que associa “transparência informacional” com “participação social” quando afirma que “(...) a participação social na formulação de políticas públicas constituiria, neste sentido, um processo inerente à transparência informacional do Estado(...)”. Portanto, no contexto atual, considerando a existência, direitos e deveres do DATASUS, seria realmente uma necessidade desenvolver sistemas de informação que, por sua vez, existem ou deveriam existir sob responsabilidade deste órgão uma vez que é designado para tal? O DATASUS atualmente está de mãos atadas, vide entrevista com Dr. Paulo Roberto, então Gestor do HOSPUB, em Junho de 2013, devido à recente aquisição de sistemas proprietários oriundos da TOTVS que eram utilizados nos Hospitais de Referencia em todo Rio de Janeiro e que atualmente está em testes nos hospitais federais incluindo o Hospital Federal do Rio de Janeiro, alvo de recente visita para acompanhamento de instalação e treinamento do sistema em questão. Tal sistema encontra-se “preso” aos sistemas proprietários da TOTVS que seriam pagos obrigatoriamente para uso do sistema adquirido pelo governo federal para repasse de tecnologia a partir de outubro do mesmo ano. Tais gastos adicionados aos custos com bancos de dados também proprietários levam o sistema ao 24 declínio e desuso justamente pelo aporte financeiro desprendido necessário para cada unidade regional de saúde contemplada. Em reunião com desenvolvedores e gestores da TOTVS viu- se a impossibilidade de “desamarrar” o sistema tanto do banco de dados quanto do ERP Proprietário que são requeridos pelo e-SUS Hospitalar, nome dado ao sistema após aquisição pelo governo federal. 2.1.2 A Importância da TI na Saúde Tecnologia da informação (TI) é um termo amplo que, além dos conceitos de sistemas de informação, engenharia de software, hardware ou informática, envolve também os aspectos humanos, gerenciais e organizacionais (LAURINDO, 2001). Autores, como ASH (1989), têm estudado a diversidade dos impactos causados pela implantação da TI sobre os indivíduos nos mais diversos ambientes organizacionais, sejam estes sociais, econômicos ou culturais, bem como analisado suas possíveis consequências. ABIDI (1999) constata que apesar das organizações de saúde gerarem grande volume de dados provenientes de prontuários eletrônicos, registros hospitalares, entre outros, estes dados raramente são utilizados no suporte à tomada de decisão. Segundo PORTER (2001), as soluções de TI permitem às empresas a obtenção de vantagem competitiva. Para tornar as aplicações mais eficientes, relacionadas à gestão eficiente dos recursos de Tecnologia da Informação (TI), existe a necessidade de um planejamento associadas às ações da área de TI a serem executadas, visando subsidiar a formulação e implementação de uma política de Saúde voltada para a Informação e economia no setor. Com o apoio dos profissionais de TI e consultores externos, as organizações deveriam utilizar a tecnologia de forma estratégica para reforçar o serviço, aumentar a eficiência e alavancar os pontos fortes existentes (PORTER, 2001). A TI altera suas operações, seus produtos e serviços, seus relacionamentos com parceiros, mercados e concorrentes (SERRA, 2002). A ética da responsabilidade suscita o desafio de desempenhar um papel estruturante em uma área de crescente importância estratégica no âmbito da saúde, pois, no cenário contemporâneo, a informação e as tecnologias a ela referidas possuem tal centralidade e relevância que sua excelência ou precariedade afeta o desenvolvimento de cada área de atividade social, a obtenção de seus objetivos e dos resultados desejados. A gestão da 25 Informação e suas tecnologias exigem macro-funções estratégicas na execução de suas ações, visando sempre o cumprimento de suas Metas. A atividade de tomada de decisão é extremamente importante para nossa vida pessoal e para o sucesso das organizações (BROWN, 2005). O processo de tomada de decisão nas organizações é complexo e envolve uma análise sob diferentes aspectos (CLEMEN e REILLY, 2001; ZOPOUNIDIS e DOUMPOS, 2002). HENDERSON e VENKATRAMAN (1999) afirmaram que, em vários países e mercados, a área de TI estava deixando de ser uma área de back-office e cada vez mais assumindo um papel estratégico, não só para dar suporte as estratégias de negócio, mas também para moldar as estratégias nas empresas. LAURINDO e ROTONDARO (2008) corroboram esta afirmação, dizendo que a TI evoluiu de uma orientação operacional de suporte administrativo para um papel mais estratégico dentro da organização. Além de organizarem a prestação dos serviços em saúde, os sistemas modernos são estruturas complexas que também organizam a utilização de milhares de produtos, processos, procedimentos e normas técnicas que visam promover, manter e recuperar a saúde da população. As intervenções médico-sanitário efetivas dirigidas à saúde da população estão impregnadas com quantidades cada vez maiores de conhecimento cientifico e tecnológico diretamente dele decorrentes. A implantação de avanços tecnológicos ou novas tecnologias é frequentemente dissociada dos problemas culturais encontrados previamente à sua implantação. Esses novos sistemas acabam forçando as pessoas a mudar sua conduta, sua linha de pensamento e sua interligação com o ambiente organizacional, tanto de forma positiva como negativa. Quando os colaboradores não estão suficientemente envolvidos na implantação de um sistema, existe o risco de uma especificação técnica ser mal direcionada, como apontar o tipo de configuração que seria mais aplicável para aquela situação, tendo, como consequência, um sistema pouco ou nada funcional (KAPLAN, 2001), reflexo da implantação de um projeto incompleto. 2.2 GERENCIAMENTO DE PROJETOS A palavra projeto pode ser utilizada nos mais diferentes contextos para exemplificar as mais diferentes situações, essa palavra muda de significado até mesmo 26 quando mudamos simplesmente o idioma. Na língua portuguesa idioma adotado no nosso país e que se defere devido as suas particularidades do idioma originado dos nossos colonizadores a palavra Projeto tem o seguinte significado: pro.je.to: sm (lat projectu) 1 Plano para a realização de um ato; desígnio, intenção. 2 Cometimento, empreendimento, empresa. 3 Redação provisória de qualquer medida (estatuto, lei etc.). 4 Constr Representação gráfica e escrita com orçamento de uma obra que se vai realizar. P. de lei: proposição escrita apresentada a uma câmara legislativa sobre qualquer assunto, para, depois de discutida em plenário, ser convertida em lei; propositura. P.-tipo: projeto padronizado que deve ser seguido em diversas obras ou instalações da mesma natureza. Pl: projetos-tipos e projetos-tipo. .(Michaelis Moderno Dicionário da Língua Portuguesa). Já no dicionário inglês, língua originária do Guia PMBOK, a mesma palavra projeto tem o seguinte significado: proj.ect: n projeto: 1 plano, desígnio, intento. 2 esquema, esboço, planta. vt+vi projetar: 1 arremessar, lançar, arrojar. 2 planear, idear. 3 tornar proeminente ou saliente. 4 fazer incidir sobre. 5 representar por meio de projeção. 6 prolongar-se, estender-se, ressaltar.(Michaelis Moderno Dicionário da Língua Portuguesa) Tomando como base o Project Management Body of Knowledge - Guia PMBOK (2013, p. 29), “Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”. Já para Ricardo Viana Vargas 1 um dos responsáveis pela tradução oficial do Guia PMBOK para o português, o significado da palavra projeto pode e deve assumir duas dimensões, uma adotada pelo próprio guia e outra também respeitada pelo PMI que define projeto como sendo uma disciplina que reúne o estudo de um projeto como, também de um programa, como também de um portfólio. Ainda para VARGAS (2009. p. 5) projeto é definido como: ...um empreendimento não repetitivo, caracterizado por uma sequencia clara e lógica de eventos, com início, meio e fim, que se destina a atingir um objetivo claro e definido, sendo conduzido por pessoas dentro de parâmetros predefinidos de tempo, custo, recursos envolvidos e qualidades. 1 Ricardo Viana Vargas especialista em gerenciamento de projetos, portfólio e riscos além de revisor reconhecido da mais importante referência no mundo sobre gerenciamento de projetos, o PMBOK Guide. Foi também um dos responsáveis pela tradução oficial do PMBOK Guide para o português 27 Para a Associação Brasileira de Normas Técnicas (ABNT) em sua Norma Brasileira (NBR) International Organization for Standardization (ISO) 10006 2 (2003, p. 02) processo é “um grupo de atividades coordenadas e controladas com datas para início e término, empreendido para alcance de um objetivo conforme requisitos específicos, incluindo limitações de tempo, custo e recursos.” Para KERZNER (2008, p. 15), “Trata-se de um empreendimento com objetivo bem definido, que consome recursos e opera sob pressões de prazos, custos e qualidade.”. Em seu livro HELDMAN (2005, p.2) diz: Os projetos destinam-se a dar origem a um servido ou produto único, que não foi produzido antes. Têm prazo limitado e sua natureza é temporária. Isto quer dizer que os projetos têm inicio e fim definidos. É possível decidir se o projeto esta concluído ao compará-lo com os objetivos e as entregas definidas no plano do projeto. Embora nas mais diversas literaturas possam sugerir os mais diversos significados para o que é projeto é certo que analisando cada um dos conceitos chega-se a conclusão que todas as opiniões e definições têm em comum que duas características são fundamentais em um projeto, unicidade e temporaneidade, ou seja, todo projeto é único e possui início e fim definido. 2.2.1 O Gerente de Projetos A pessoa responsável pelo gerenciamento de um projeto é chamada gerente de projetos, para esse papel é escolhido um profissional preparado com habilidades especificas como liderança, comunicação, capacidade de negociação e na resolução de problemas além da boa influência na organização, já no que tange o conhecimento técnico, isso não é o ponto crucial para um gerente de projetos, uma vez que sua competência está mais voltada para o entendimento geral do que para o específico. Algumas das habilidades mais importantes que você precisa ter para ser gerente de projeto são excelente comunicação verbal e escrita, boa organização, capacitação geral de gerência, tais como elaboração de orçamento e criação de equipe, habilidades em negociação e solução de problemas e capacidade de comunicação interpessoal. Gerenciamento de projetos não se restringe a ter um conjunto de habilidades, ou dominar uma forma de fazer uma coisa; ao contrário, tem muito a ver com saber de tudo um pouco. Os gerentes de projetos são definidos “um quilômetro de largura, um centímetro de profundidade”. (HELDMAN, 2005, p.28) 2 Normatiza a Gestão da qualidade - Diretrizes para a qualidade no gerenciamento de Projetos 28 Além de ser responsável por todo o projeto muitas vezes são congratulados pelo seu sucesso e, em muitas outras, responsabilizadas pelo seu fracasso. O gerente de projetos atualmente ganha destaque dentro das organizações pela evolução e relevância do gerenciamento de projetos. A profissão de gerenciamento de projetos é emergente e bastante promissora. 2.2.2 Gerenciamento de Projetos e a sua Importância Um projeto para ser executado precisa ser gerenciado e segundo o Guia PMBOK (2013, p. 31), “Gerência de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, a fim de atender aos seus requisitos.”. HELDMAN (2005, p.2) diz que “gerenciamento de projetos: Métodos de atender aos requisitos do projeto para satisfação do cliente por meio de planejamento, execução, monitoramento e controle dos resultados do projeto”. O Gerenciamento de Projetos surgiu como ciência no início da década de 60 (sessenta), No decorrer das décadas o gerenciamento de projetos evoluiu devido as grandes pressões impostas pelo mundo moderno devido ao grande crescimento alavancado principalmente pela explosão tecnológica. Mas foi a partir da criação do PMI em 1969 que a sua disseminação ocorreu com maior intensidade. A importância do gerenciamento de projetos foi demonstrada através de números por meio de algumas pesquisas feitas pelo The Standish Group que publica periodicamente o Chaos Report, uma espécie de relatório sobre os sucessos e fracassos no que diz respeito a projetos. Nos Chaos Report é notório o crescimento do numero de projetos que estão tendo sucesso. Mas qual o motivo desse crescimento numérico? Levando em consideração que as empresas estão cada vez mais focadas em projetos e que o reconhecimento da importância da gerência de projetos ocorre devido à certeza que com isso irão obter um resultado satisfatório e números bastante expressivos sobre o impacto na lucratividade da empresa. Isso tudo ocorre porque ao adotar a gerência de projetos na sua forma mais eficaz podemos ter inúmeros benefícios como; a ausência de surpresas durante a execução dos trabalhos; desenvolvimento de diferenciais competitivos; precipitação de situação desfavorável; adaptação dos trabalhos; antecipação do orçamento, decisões mais ágeis; 29 aumento do controle gerencial; facilitação as revisões do projeto; melhor o rendimento dos recursos humanos e documentação dos projetos. Podemos assim afirmar que a gerência de projetos é o grande responsável para que isso ocorra e que a tendência é uma evolução do panorama em proporções cada vez maiores. 2.2.3 Project Management Institute – PMI No seu site a Project Management Institute (PMI) se intitula como sendo, uma das maiores as associações de membros profissionais do mundo com meio milhão de membros e credenciados em mais de 185 países. Ainda no mesmo site temos a seguinte definição sobre o PMI: É uma organização sem fins lucrativos que promove a profissão de gerenciamento de projetos através de padrões mundialmente reconhecidos e certificados, comunidades colaborativas, um extenso programa de pesquisa e oportunidades de desenvolvimento profissional. A história do PMI começa no ano de 1969, no Instituto de Tecnologia da Georgia, na cidade de Atlanta, Estado da Georgia, EUA, quando os cinco profissionais de gestão de projetos – James Snyder, Eric Jenett, Gordon Davis, “Ned” Engman e Susan Gallagher, se reuniram para discutir as melhores práticas sobre gerenciamento de projetos e assim fundaram o Project Management Institute - PMI (EUA). Ainda em 1969 na cidade de fundação aconteceu o primeiro seminário e simpósio, PMI Seminars & Symposium, evento que passou a acontecer anualmente, desse encontro participarão 83 pessoas. Nos anos 70 foi realizado o primeiro Seminars & Symposium realizado fora dos EUA, nele foi oficializado o primeiro capitulo do PMI além de estabelecer seu Programa de Prêmios Profissionais, nessa mesma década surgiu à primeira edição do Project Management Quarterly (PMQ), renomeada posteriormente para Project Management Journal (PMJ) e impresso até hoje trimestralmente. No fim desta década, o PMI somava mais de 2.000 (dois mil) associados no mundo. A década de 80 foi marcada pelo crescimento dos números programas e serviços oferecidos pelo PMI. Nessa mesma década foi adotado um código de ética para a profissão de gestão de projetos e foi certificado o primeiro Project Management Professional – PMP em 30 1984 em um simpósio na Filadélfia, EUA, na ocasião eram adotadas apenas seis áreas de conhecimento. Ainda na década de 80 foi publicado o PMQ Special Report on Ethics Standards and Accreditation, primeiro modelo padrão de gerenciamento de projetos. Além dele foi co- publicado o primeiro livro do PMI intitulado The implementation of Project Management: the professional’s handbook (A implementação do Gerenciamento de Projetos: manual do profissional) com 8000 cópias vendidas Em 1987 nasceu a PMNetwork, revista mensal do PMI que circula até os dias atuais, sendo sua publicação mensal, nela foi publicada a primeira versão do Guia PMBOK com 08 (oito) áreas de conhecimento, na mesma década foi criada a divisão de publicações da PMI no Estado da Carolina do Norte, EUA. Na década de 90 com mais de 8.500(oito mil e quinhentos) associados, números que em 1993 passou a crescer 20% (vinte por cento) ao ano, chegando ao final dessa década com algo em torno de 50(cinquenta) mil associados, a PMI criou os Grupos de Interesses Específicos, os Colleges e o Seminars USA, uma série de programas educacionais em gerenciamento de projeto mais tarde renomeado como World Seminars, criou também Programa de Desenvolvimento Profissional (Professional Development Program – PDP) para que os profissionais certificados como PMP mantenham sua certificação. Ainda na década 90 foi publicado e distribuído o primeiro exemplar do PMI Today, boletim informativo mensal do PMI, finalmente em 1996, foi publicada pela primeira vez de forma independente o Guide to the Project Management Body of Knowledge (Guia PMBOK), já com as 09 (nove) áreas de atuação, sendo logo adotado como padrão pelo Instituto de Engenheiros Eletricistas e Eletrônicos (Institute of Electrical and Electronics Engineers - IEEE), intitulada norma IEEE Std 1490-1998. Em 1999 o Programa de Certificação foi reconhecido pela ISO 90016 logo após em 2000 foi lançada a segunda versão do O Guia PMBOK, no mesmo ano foi adotado como Padrão Nacional Americano (American National Standard - ANS), norma ANSI/PMI 99-001- 2000 e pelo Instituto de Padrões Nacional Americano (American National Standard Institute - ANSI). Até os dias atuais o PMI publicou três novas atualizações para o Guia PMBOK, em 2004 a 3ª Edição publicada com a maior alteração desde o seu lançamento, em 2008 a 4ª Edição e finalmente em 2013 a 5ª Edição com isso demonstrando seu compromisso com a expansão e melhoria contínua do guia, assim como com o desenvolvimento de padrões adicionais. 31 No site da PMI internacional é informado que a empresa possui nos dias atuais mais de 600.000 membros credenciados em mais de 185 países. Os números confirmam a aceitação dos profissionais pela metodologia e pelos pensamentos adotados pela PMI e a sua incontestável liderança como associação profissional em gerenciamento de projetos. Provavelmente devido ao interesse em difundir e discernir os conhecimentos e a formação sobre gerenciamento de projetos, além de oferecer inúmeras oportunidades para os profissionais, interessados e empresas que desejam estabelecer relacionamentos e colaborarem com PMI no avanço e no desenvolvimento do gerenciamento de projetos. A certificação PMP do PMI é a credencial mais reconhecida mundialmente para indivíduos envolvidos com o gerenciamento de projetos e o Guia PMBOK a metodologia mais utilizada na gerencia de projetos por profissionais e empresas. 2.2.4 PMBOK: Guia de Conhecimento em Gerência de Projetos 2.2.4.1 A história do Guia PMBOK Segundo DINSMORE e CABANIS-BREWINO (2009, p. 17), “Project Management Institute – PMI produziu o mais antigo e mais utilizado dos conjuntos de conhecimentos em gerenciamento de projetos”. Derivação do Ethics, Standards and Accreditation (ESA) tendo como tradução Ética, Padrões e Credenciamento, Project Management Body of Knowledge - PMBOK teve sua primeira impressão em 1987, embora a maioria dos autores considere a impressão de 1996 com primeira edição, pois apenas nela estavam contidas e separadas as nove áreas de conhecimento com os seus devidos processos num total de 39 (trinta e nove) processos. A publicação foi atualizada para segunda versão em 2000, terceira em 2004, em seguida em 2008 foi publicada a quarta edição que contava com 42 (quarenta e dois) processos estruturados em 05 (cinco) grupos e em 09 (nove) áreas de atuação, finalmente em 2013 houve a publicação mais recente que a partir de agora passava a contar com 47 (quarenta e sete) processos estruturados nos mesmos 05 (cinco) grupos de processos, porém agora em 10 (dez) áreas de atuação que descrevem “o que” deve ser feito e não “como” fazer (Figura 1) incluindo a mais nova área de conhecimento “Gerenciamento de Stakeholders”. 32 Figura 1 - Constituição numérica PMBOK 2013 Fonte: D'ÁVILA, 2010, atualizado pelo autor. No Guia PMBOK podemos encontrar os conhecimentos necessários na área de gerência de projetos atrelados as melhores práticas. Conhecimento esse comprovado no decorrer dos tempos e nas diversas atualizações e utilizações do guia em grandes ou pequenos projetos. Na sua mais nova edição o Guia PMBOK (2013) leva em consideração fatores como aplicação de conhecimentos, processos, habilidades, ferramentas e técnicas como membros primordiais para o sucesso de um projeto. Apesar de ser considero mundialmente uma referencia básica no que diz respeito a gerenciamento de projetos o Guia PMBOK não pode ser visto como abrangente nem completo, pois fornecer apenas uma visão geral do conjunto de conhecimento, logo não sendo caracterizado com uma metodologia de gerenciamento de projetos. Para o desenvolvimento deste trabalho serão focadas todas as áreas de conhecimento do Guia PMBOK. 33 2.2.4.2 Grupos de Processos da Gerência de Projetos no Guia PMBOK Segundo o Guia PMBOK (2013, p. 74): “Os processos de gerenciamento de projetos são agrupados em cinco categorias, conhecidas como grupos de processos de gerenciamento de projetos (ou grupo de processos)”. Esses grupos dão origem a fases que possuem nome similar ao grupo a que ela representa.  Grupos de processos de iniciação: Realizados para reconhecer a iniciação do projeto ou de uma de suas fases, havendo a autorização para o início;  Grupos de processos de planejamento: Englobam processos que estabelecem o desenvolvimento e manutenção de um esquema de trabalho para o acompanhamento de demandas que o projeto compromete-se a atender;  Grupos de processos de execução: São processos que responsáveis por coordenar a execução das atividades do projeto. Com visão na satisfação das especificações;  Grupos de processos de monitoramento e controle: Responsáveis pela monitoração e posterior validação dos objetivos alcançados pelo projeto além de identificação das mudanças e iniciá-las, quando for necessário.  Grupos de processos de encerramento: Nele é feita a aceitação formal do produto gerado pelo projeto ou por suas fases, ou ainda o encerramento do projeto ou da fase. A aplicação e a integração desses grupos (Figura 2) são essenciais para o gerenciamento de um projeto. 34 Figura 2 - Interação entre grupos de processos de gerenciamento de projetos Fonte: Guia PMBOK 2013 Os cinco grupos de processos do Guia PMBOK estão ligados entre si pelo resultado que produzem. O produto de saída de um grupo torna-se produto de entrada para o outro grupo. 2.2.4.3 Áreas de Atuação do Guia PMBOK A organização do Guia PMBOK é feita por área de conhecimento nele é descrito as boas práticas e a documentação necessária para cada uma delas, onde cada área é descrita através de processos agrupados de acordo com os 05(cinco) grupos de processos para gerenciamento de projetos. Cada processo se refere a um aspecto a ser considerado dentro da gerência de projetos. Os processos de gerenciamento de projetos são geralmente introduzidos como distintos e com fronteiras comuns definidas, enquanto na prática, os mesmos sobrepõem-se e interagem de maneira que não podem ser completamente detalhadas no Guia PMBOK. ( Guia PMBOK, 2013, p. 89). As áreas de conhecimento do Guia PMBOK relatam conhecimentos e práticas de gerenciamento de projetos dalas fazem parte um ou mais processos. Os processos são descritos de acordo com as suas entradas (documentos ou itens documentáveis), saídas (documentos ou itens documentáveis), ferramentas e técnicas (mecanismos utilizados para produzir as saídas). 35 2.2.4.3.1 Gerenciamento da Integração A área de conhecimento em gerenciamento de integração do projeto descreve os processos para identificar, definir, combinar, unificar e coordenar adequadamente os diversos elementos do projeto, sejam eles atividades ou processos, com a finalidade de atingir as necessidades e expectativas de todas as partes interessada. Processos do gerenciamento da integração (Guia PMBOK, 2013, p. 89): Desenvolver o Termo de abertura do projeto (Project Charter) – O processo de desenvolvimento de um documento que formalmente autoriza um projeto ou uma fase e a documentação dos requisitos iniciais que satisfaçam as necessidades e expectativas das partes interessadas. Desenvolver o plano de gerenciamento do projeto – O processo de documentação das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares. Orientar e gerenciar a execução do projeto - O processo de realização do trabalho definido no plano de gerenciamento do projeto para atingir os objetivos do projeto. Monitorar e controlar o trabalho do projeto - O processo de acompanhamento, revisão e regulação do progresso para atender os objetivos de desempenho definidos no plano de gerenciamento do projeto. Realizar o controle integrado de mudanças - O processo de revisão de todas as solicitações de mudança, aprovação de mudanças e gerenciamento de mudanças nas entregas, ativos de processos organizacionais, documentos de projetos e plano de gerenciamento de projetos. Encerrar o projeto ou fase - O processo de finalização de toas às atividades de todos os grupos de processos de gerenciamento de projetos para terminar formalmente o projeto ou a fase. Dentre os grupos do guia PMBOK o gerenciamento da integração é o único se encontra presente em todas as fases processos da gerência de projetos a figura 4 demonstra isso. Figura 3 - Processos de gerenciamento da integração distribuídos ao longo das fases Fonte: VARGAS, 2009 36 2.2.4.3.2 Gerenciamento do Escopo O gerenciamento de escopo é responsavel por controlar o que deve ou não estar incluso em um projeto, proporcionando assim que o projeto seja finalizado com sucesso apenas com o trabalho necessario, faz parte dos seus processos: coletar requisitos; definição do escopo; criar a estrutura analítica do projeto - EAP ou Work Breakdown Structure 3 - WBS, verificação do escopo e controle do escopo. Processos do gerenciamento do escopo (Guia PMBOK, 2013, p. 131): Planejar o gerenciamento do escopo – O processo de criar um plano de gerenciamento de escopo que documenta como o escopo do projeto será definido, validado e controlado. Coletar Requisitos – O processo de definição e documentação das necessidades das partes interessadas para alcançar os objetivos do projeto. Definir o escopo - O processo de desenvolvimento de uma descrição detalhada do projeto e do produto. Criar a EAP– O processo de subdivisão das entregas e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis. Validar o escopo - O processo de formalização da aceitação das entregas terminadas do projeto Controlar o escopo - O processo de monitoramento do progresso do escopo do projeto e escopo do produto e gerenciamento das mudanças feitas na linha de base do escopo. 2.2.4.3.3 Gerenciamento de Tempo O gerenciamento de tempo do projeto administra o tempo e o cronograma do projeto através de representações gráficas das tarefas planejadas e realizadas, atrasadas ou em dia, bem como a dependência entre elas os marcos (milestones) existentes no projeto além dos recursos utilizados ao final do projeto. Seus processos são: definição das atividades; sequenciamento das atividades; estimativa de recursos das atividades; estimativa de duração das atividades; desenvolvimento do cronograma; e controle do cronograma. Processos do gerenciamento do tempo (Guia PMBOK, 2013, p. 167): Planejar o gerenciamento do cronograma – O processo de estabelecer as políticas, procedimentose documentação ao planejar, desenvolver, gerenciar, executar e controlar o cronograma do projeto. Definir as atividades – O processo de identificação das ações específicas a serem realizadas para produzir as entregas do projeto. 3 Work Breakdown Structure – Decomposição hierárquica orientada à entrega do trabalho a ser executado pela equipe do projeto para atingir os objetivos do projeto e criar as entregas necessárias. Ela organiza e define o escopo total do projeto. 37 Sequenciar as atividades - O processo de identificação e documentação dos relacionamentos entre as atividades do projeto. Estimar os recursos da atividade - O processo de estimativa dos tipos e quantidade de material, pessoas, equipamentos ou suprimentos que serão necessários para realizar cada atividade. Estimar as durações da atividade - O processo de estimativa do número de períodos de trabalho que serão necessários para terminar as atividades específicas com os recursos estimados. Desenvolver o cronograma - O processo de análise das sequências das atividades suas durações, recursos necessários e restrições do cronograma visando criar o cronograma do projeto. Controlar o cronograma - O processo de monitoramento do andamento do projeto para atualização do seu progresso e gerenciamento das mudanças feitas na linha de base do cronograma. Ainda dentro do gerenciamento de tempo do projeto é feito o estudo para a fase mais importante, quando se identifica o caminho crítico do projeto, o qual se define baseado no diagrama usado pelo Gerente de Projetos, neste caso o Gráfico de Gantt 4 . O diagrama de Gantt é uma forma de representar graficamente o calendário das atividades do projeto e respectivas dependências. Nele estão representadas as atividades do projeto num espaço bidimensional em que, na horizontal está marcado o tempo de duração do projeto, numa escala que pode ser de dias, semanas ou meses e na horizontal se encontram as diversas atividades do projeto. No diagrama de Gantt as atividades do projeto são representadas como barras horizontais em que o comprimento é relativo á duração estimada para a atividade. As interdependências entre atividades são representadas por linha que interligam duas ou mais atividades. O PMBOK (2013) define os 4 tipos de interdependências ou relacionamentos lógicos 5 a serem utilizados durante a construção do diagrama de Gantt como mostrado na Figura 4 e consequente sequenciamento das atividades, listados a seguir:  Início para término: O término do trabalho da atividade sucessora do cronograma depende da iniciação da atividade predecessora do cronograma; 4 Gráfico de Gantt – Definido pelo PMBOK 2013 como uma representação gráfica de informações relacionadas ao cronograma. Em um gráfico de barras típico, as atividades do cronograma ou os componentes da estrutura analítica do projeto são listados verticalmente do lado esquerdo do gráfico, as datas são mostradas horizontalmente na parte superior e nas durações das atividades são exibidas como barras horizontais posicionadas de acordo com as datas. 5 Dependência entre duas atividades do cronograma do projeto ou entre uma atividade do cronograma do projeto em um marco do cronograma. 38  Início para início: A iniciação do trabalho da atividade sucessora do cronograma depende da iniciação da atividade predecessora do cronograma;  Término para início: A iniciação do trabalho da atividade sucessora do cronograma depende do término do trabalho da atividade predecessora do cronograma;  Término para término: O término do trabalho da atividade sucessora do cronograma não pode terminar até o término do trabalho da atividade predecessora do cronograma; “O Método do Diagrama de Precedência é um Método Usado no Método do Caminho Crítico – CPM, para a construção de um diagrama de rede do cronograma do projeto e que utiliza quadrados ou retângulos, chamados de nós, para representar as atividades e conectá-las com flechas que indicam as relações lógicas que existem entre elas” (PMBOK 2013, p182). Figura 4: Relacionamentos Lógicos do MDP Fonte: PMBOK 2013 Existem também as atividades marco que são representadas por pequenos losangos que representam um evento específico em um determinado momento do projeto e não em um período de tempo. No diagrama Gantt pode-se também incluir informações sobre o estado atual do projeto, alterando a cor das atividades para diferenciar as que estão completas das que estão em curso, e também das que ainda não foram iniciadas. 39 Adicionalmente, a inclusão de uma linha vertical que marca a data de hoje tem a vantagem de permitir rapidamente a percepção de eventuais atrasos nas atividades do projeto. É igualmente possível sobrepor o cronograma planejado com o cronograma efetivo de forma a visualizar as diferenças entre os dois, esta linha é chamada linha de base. 2.2.4.3.4 Gerenciamento de Custos O gerenciamento de custo engloba os processos responsáveis para que um projeto termine respeitando o máximo possível o orçamento aprovado. Os seus processos são: Estimar os custos; Determinar o orçamento; e Controlar os custos. Processos do gerenciamento dos custos (Guia PMBOK, 2013, p. 219): Planejar o gerenciamento de custos – O processo de estabelecer as políticas, procedimentos, e documentação ao planejar, gerenciar, despender, e controlar os custos do projeto. Estimar os custos – O processo de desenvolvimento de uma estimativa de custos dos recursos monetários necessários para terminar as atividades do projeto. Determinar o orçamento – O processo de agregação dos custos estimados de atividades individuais ou pacotes de trabalho para estabelecer uma linha de base autorizada dos custos. Controlar os custos – O processo de monitoramento do andamento do projeto para atualização do seu orçamento e gerenciamento das mudanças feitas na linha de base dos custos. 2.2.4.3.5 Gerenciamento da Qualidade Na área de atuação gerencia da qualidade de um projeto são determinado os padrões de qualidade para que o projeto seja concebido de acordo com as exigências da empresa contratante, a gestão da qualidade é exercida continuamente durante todo o projeto, os processos que fazem parte dessa gerência são: Planejar a qualidade; Realizar a garantia da qualidade; e Realizar o controle da qualidade. Processos do gerenciamento da qualidade (Guia PMBOK, 2013, p. 253): Planejar a qualidade – O processo de identificar os requisitos e/ou padrões de qualidade do projeto e do produto, bem como documentar de que modo o projeto demonstrará a conformidade. Realizar a garantia da qualidade – O processo de auditoria dos requisitos de qualidade e dos resultados das medições de controle de qualidade para garantir que sejam usados os padrões de qualidade e as definições operacionais apropriadas. 40 Realizar o controle da qualidade – O processo de monitoramento e registro dos resultados da execução das atividades de qualidade para avaliar o desempenho e recomendar mudanças necessárias. 2.2.4.3.6 Gerenciamento dos Recursos Humanos O gerenciamento de recursos humanos provê a constante organização das equipes do projeto de acordo com as necessidades deste frente habilidades dos membros da equipe, garantindo com isso o melhor aproveitamento das pessoas envolvidas no projeto. Seus processos englobam: Desenvolver o plano de recursos humanos; Mobilizar a equipe do projeto; desenvolver a equipe do projeto; e Gerenciar a equipe do projeto. Processos do gerenciamento dos recursos humanos (Guia PMBOK, 2013, p. 281): Desenvolver o plano de recursos humanos – O processo de identificação e documentação de funções, responsabilidades, habilidades necessárias e relações hierárquicas do projeto, além da criação de um plano de gerenciamento de pessoal. Mobilizar a equipe do projeto – O processo de confirmação da disponibilidade dos recursos humanos e obtenção da equipe necessária para concluir as designações do projeto. Desenvolver a equipe do projeto – O processo de melhoria de competências, interação da equipe e ambiente global da equipe para aprimorar o desempenho do projeto. Gerenciar a equipe do projeto – O processo de acompanhar o desempenho de membros da equipe fornece feedback6, resolver questões e gerencia mudanças para otimizar o desempenho do projeto. 2.2.4.3.7 Gerenciamento das Comunicações A comunicação é uma atividade que acontece a maior parte do tempo em um projeto, o seu gerenciamento visa assegurar a produção, coleta, distribuição, armazenagem, recuperação e organização apropriada e constante das informações do projeto, a gerência de comunicações se subdivide em cinco processos: Identificar as partes interessadas; Planejar as comunicações; Distribuir informações; Gerenciar as expectativas das partes interessadas; e Repostar o desempenho. Processos do gerenciamento das comunicações (Guia PMBOK, 2013, p. 313): 6 Feedback - Significa realimentar ou dar o retorno e tem a capacidade de dar e receber opiniões, críticas e sugestões sobre alguma coisa pessoal ou profissional., definição retirada do site: http://www.administradores.com.br/informe-se/producao-academica/feedback/2878/ 41 Planejar as comunicações – O processo de determinação das necessidades de informação das partes interessadas no projeto e definição de uma abordagem de comunicação. Gerenciar as comunicações – O processo de criar, coletar, distribuir, armazenar, e recuperar exibindo a disposição final das informações do projeto de acordo com o plano de gerenciamento das comunicações. Controlar as comunicações – O processo de monitorar e controlar as comunicações através do completo ciclo de vida do projeto para se certificar que as informações necessárias dos interessados do projeto serão atendidas. Segundo o Guia PMBOK, o gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. 2.2.4.3.8 Gerenciamento dos Riscos Os riscos do projeto são algo tão incerto de acontecer quanto os seus efeitos sobre o mesmo, a gerência de riscos do projeto visa planejar, indentificar, analisar, monitorar, controlar bem como projetar respostas para os possiveis riscos de um projeto. Com isso maximizando a probabilidade e o impacto dos eventos positivos e minimizando as probabilidade e o impacto dos eventos negativos para o projeto. Seus processos são: Planejamento do gerenciamento de riscos; Identificação de riscos; Análise qualitativa de riscos; Análise quantitativa de riscos; Planejamento de respostas a riscos; e Monitoramento e controle de riscos. Processos do gerenciamento de riscos (Guia PMBOK, 2013, p. 335): Planejar o gerenciamento dos riscos – O processo de definição de como conduzir as atividades de gerenciamento dos riscos de um projeto Identificar os riscos – O processo de determinação dos riscos que podem afetar o projeto e de documentação de suas características. Realizar a análise qualitativa dos riscos – O processo de priorização dos riscos para análise ou ação adicional através de avaliação e combinação de sua probabilidade de ocorrência e impacto. Realizar a análise quantitativa dos riscos – O processo de analisar numericamente o efeito dos riscos identificados, nos objetivos gerais do projeto. Planejar as respostas aos riscos – O processo de desenvolvimento de opções e ações para aumentar as oportunidades e reduzir as ameaças aos objetivos do projeto. Monitorar e controlar os riscos – O processo de implantação de planos de respostas aos riscos, acompanhamento dos riscos identificados, monitoramento dos riscos residuais, identificação de novos riscos, e avaliação de eficiência durante todo o projeto. 42 2.2.4.3.9 Gerenciamento das Aquisições O gerenciamento de aquisições envolve um grupo de processos imprescindíveis para a compra ou aquisição de bens e serviços, além de gerenciar os contratos e as suas mudanças. Em um projeto o contrato tem um papel muito importante, pois define um acordo gerando obrigações entre as partes obrigando que se cumpra o prometido disposto no contrato sob a pena de multas e outras penalidades se concretizando uma relação legal. Entre seus processos estão: Planejar as aquisições; Realizar as aquisições; Administrar as aquisições; e Encerrar as aquisições. Processos do gerenciamento das aquisições (Guia PMBOK, 2013, p. 381): Planejar as aquisições – O processo de documentação das decisões de compras do projeto, especificando a abordagem e identificando fornecedores em potencial. Conduzir as aquisições – O processo de obtenção de resposta de fornecedores, seleção de fornecedores e adjudicação de um contratos. Controlar as Aquisições – O processo de gerenciamento das relações de aquisição, monitorando o desempenho do contrato e realização de mudanças e correções conforme necessário. Encerrar as Aquisições – O processo de finalizar todas as aquisições do projeto. 2.2.4.3.10 Gerenciamento das Partes Interessadas O gerenciamento de stakeholders é uma das disciplinas fundamentais da base de conhecimentos do gerente de projetos. O sucesso dos projetos é medido pelo grau de satisfação das partes envolvidas no mesmo. Para alcançar este grau de satisfação e garantir o sucesso do projeto é necessário identificar e conhecer as características, expectativas e papéis de cada uma das partes envolvidas. A partir do conhecimento de cada stakeholder, o gerente de projetos deve buscar o seu comprometimento, motivação e cooperação. Por meio destes fatores, o gerente do projeto vence as dificuldades e empecilhos, buscando a excelência no relacionamento entre as partes e diminuindo assim os riscos de insucesso no projeto. Focado em garantir o sucesso do projeto a partir do gerenciamento de stakeholders, este artigo tem como objetivos: investigar as dificuldades encontradas, apresentar técnicas, medidas e metodologias que o gerente de projetos precisa conhecer para alcançar a satisfação das partes envolvidas. Processos do gerenciamento das partes interessadas do projeto (Guia PMBOK , 2013, p. 417): 43 Identificar as partes interessadas - É o processo de identificação de todas as pessoas ou organizações que podem ser afetadas pelo projeto e documentação das informações relevantes relacionadas aos seus interesses, envolvimento e impacto no sucesso do projeto; Planejar o gerenciamento das partes interessadas - Tem como objetivo desenvolver estratégias para quebrar as resistências das partes interessadas e garantir seu engajamento no projeto; Gerenciar o engajamento das partes interessadas - é o processo de comunicação e interação com as partes interessadas para atender às suas necessidades e solucionar as questões à medida que ocorrerem; Controlar o engajamento das partes interessadas - monitorar os relacionamentos entre as partes interessadas e ajustar as estratégias para engajar as partes interessadas eliminando resistências e aumentando o suporte ao projeto. Figura 5: Relações entre os Stakeholders e o Projeto (PMBOK 2013) Fonte: PMBOK 2013 2.2.4.4 Grupos de Processos e suas Áreas de Atuação Todo projeto passa pelos 05 (cinco) grupos de processos de gerenciamento de projetos, explicitados no item 2.2.4.2 deste trabalho, e durante sua concepção poderá chegar a ser aplicado e integrado até 47 processos que estão distribuídos e agrupados logicamente nesses grupos (Figura 6). 44 Figura 6 - Interação entre grupos de processos de gerenciamento de projetos Fonte: Guia PMBOK 2013, modificado pelo autor. O agrupamento dos processos em cada fase do projeto resulta em um marco ao final de cada uma delas. Ao termino da fase de iniciação teremos em mão o termo de abertura do projeto, para a fase de planejamento teremos o plano de gerenciamento do projeto, ao termino da execução teremos o projeto propriamente dito e o relatório de mudanças que marca também a finalização da fase de monitoramento e controle e no ato de encerramento do projeto teremos a consolidação de todos os documentos referentes ao projeto. 2.2.4.5 Classificação e Complexidade de Projetos Geralmente as organizações classificam os projetos de acordo com o custo, tamanho do escopo, quantidade de recursos empreendidos ou dimensionamento de prazos e por isso a primeira impressão é que alguns projetos dependendo destas variáveis não necessitam de gerenciamento. Mas essa visão não é consensual, segundo PASSOS (2008a, p. 1): Qualquer projeto necessita ser planejado e controlado, a fim de não ser posto em condições de risco. Por menor ou pouco importante que pareça, ainda assim, um determinado nível de gerenciamento deve ser aplicado. Desconsiderar esse aspecto pode levar muitos projetos ao fracasso. 45 Tabela 1: Classificação de Projetos segundo Passos (2008a) Fonte: PASSOS (2008a, p. 3) KROLL (2007, p. 30) destaca que a complexidade de um projeto pode variar significativamente de uma organização para outra quando afirma que “(...) um projeto que é pequeno para uma corporação multinacional pode ser bastante grande se empreendido por outra organização”. PARTH (1998, p. 2) identifica o tamanho dos projetos utilizando dois indicadores: a) o impacto do projeto nos resultados da empresa e b) a dedicação dos recursos ao projeto. O tipo de projeto depende do tempo de dedicação do gerente do projeto e da equipe do projeto, mas atualmente é cada vez mais difícil encontrar projetos com dedicação exclusiva tanto dos recursos quanto do gerente do projeto principalmente no serviço público. Uma classificação bem “intuitiva” baseada na numeração de uma peça de vestuário é apresentada por RINCON (2006, p. 2), chamada de conceito “T-Shirt Size” ou “tamanho de camiseta”, que pode ser Grande, Médio ou Pequeno. Projetos Grandes são aqueles com uma estimativa de trabalho superior a 120 horas e são denominados projetos, os Médios possuem estimativas de 40 a 120 horas de trabalho e são chamados de mini-projetos 46 e os Pequenos ou micro-projetos possuem estimativas de 8 a 40 horas. Porém a classificação dos projetos apenas pela quantidade de horas é muito limitada. Já ANYOSA (2008, p. 2) classifica os projetos de acordo com seus níveis de complexidade como básica, moderada e extrema utilizando como base diversas questões para cada uma das dez áreas de conhecimento do PMBOK Guide. Para cada questão deve-se dar uma nota de 1 (muito baixa) a 5 (muito alta) para sua complexidade. O nível de complexidade do projeto é obtido então pela média dos pontos obtidos nas dez áreas, classificando os projetos de acordo com sua pontuação: complexidade baixa < 2.5, média < 3.5 e alta >= 3.5. Este método acerta ao sugerir um modelo parametrizável, mas uma avaliação muito detalhada do projeto é exigida, e isso dificulta o processo além do fato de todas as questões possuírem o mesmo peso, não refletindo as prioridades da organização torna a classificação bem mais complexa. Em compensação, essa avaliação é excelente para o gerente do projeto identificar a complexidade do projeto e assim definir qual a melhor abordagem para o seu gerenciamento. THORN e DIXON (2004, p. 5-6) propõem três níveis de esforços no gerenciamento de projetos: completo, simplificado e nenhum: O Gerenciamento de Projetos Completo envolve a atribuição de um gerente de projetos e a utilização completa da metodologia definida pelo escritório de projetos (PMO – Project Management Office); O Gerenciamento de Projetos Simplificado também envolve a atribuição de um gerente de projetos, mas possui liberdade para aplicar os processos da metodologia de acordo com o tamanho e complexidade do projeto. Em Nenhum Gerenciamento Formal de Projetos a responsabilidade do projeto cai sobre um membro da equipe (não possui um gerente de projetos designado) e não se espera que seja utilizada uma metodologia de projetos. Espera-se com isso reduzir custos e evitar a utilização e um gerente num projeto em que ele não é necessário. O gerenciamento de projetos ajuda as organizações a atenderem as necessidades de seus clientes padronizando tarefas rotineiras e reduzindo o número daquelas que poderiam ser esquecidas. Também assegura que os recursos disponíveis são alocados da maneira mais eficiente e eficaz, permitindo aos executivos seniores a perceber “o que está acontecendo” e “para onde as coisas estão indo” dentro das organizações. Muitos projetos grandes são divididos em projetos menores e a utilização de uma metodologia adequada ao tamanho do projeto facilita o seu gerenciamento e traz agilidade. Para VARGAS (2009, p. XIV), os benefícios que uma organização pode obter com o uso de gerenciamento de projetos são o aumento da confiança e da segurança do empreendedor; melhor controle dos projetos, melhor administração de mudanças e maior número de projetos bens sucedidos devido à melhora na performance, ao aumento da 47 eficiência e da eficácia. Dentre os benefícios que a organização obtém com o gerenciamento de projetos, destacam-se o comprometimento com os objetivos e a melhoria da tomada de decisão. O “Estudo de Benchmarking em gerenciamento de projetos Brasil” (PMI, 2008b) obteve através de pesquisa com as principais empresas brasileiras os seis maiores benefícios obtidos com o gerenciamento de projetos: Maior comprometimento com os objetivos e resultados Disponibilidade de informações para tomada de decisões Melhoria da qualidade nos resultados dos projetos Minimização dos riscos em projetos Maior integração entre as áreas Aumento de satisfação do cliente (interno/externo) 2.2.4.6 O Escritório de Projetos Recentemente, os estudos sobre a gestão de projetos têm ganhado força devido ao aumento da complexidade do mundo dos negócios e à crescente competitividade empresarial. Neste contexto, as falhas na execução dos projetos têm resultados desastrosos. Para evitar que elas ocorram, diversos mecanismos vêm sendo desenvolvidos. O Escritório de Projetos é um destes mecanismos. O Escritório de Projetos (EP) surge, então, como um elemento organizacional responsável pela minimização dos problemas de falta de processos definidos e padronizados, pela divulgação das práticas de gerenciamento de projetos para toda a organização, possibilitando a diminuição dos índices de falhas e garantindo que os projetos mais importantes para a organização sejam os mais prioritários. Não há um padrão definido para Escritório de Projetos, varia de autor para autor. Autores como KERZNER (2004), CRAWFORD (2006) e MANSUR (2007) classificam seus EP, quase exclusivamente, pela posição hierárquica ocupada pelo EP dentro da corporação. Já DINSMORE (1998) e VERZUH (2005) utilizam como critério para sua classificação, a missão atribuída ao EP. De acordo com a estrutura organizacional encontrada na SESAP situando a SUININ em posição que não condiz com as melhores práticas de TI segundo relatório do TCE(2013), os estudos serão centralizados na missão atribuída ao Escritório de Projetos, considerando as responsabilidades e participação de cada membro e relevância das atividades desenvolvidas uma vez que a posição atual da SUININ na estrutura organizacional da SESAP não atende aos requisitos para uma boa gestão de TI dentro do órgão com relação ao EP. 48 Deve-se deixar muito bem claros os seus objetivos e estes devem ser divulgados por toda a organização (PMI, 2004). De acordo com suas responsabilidades e funcionalidades os escritórios de projetos podem ser classificados em diferentes tipos. A classificação proposta por VERZUH (2005) define cinco tipos de escritórios de projetos: • Centro de Excelência (Center of Excellence – CE): Atua como uma espécie de “conselheiro” para os gerentes de projetos. Mantem os padrões de gestão de projeto e promove sua utilização. Não participa diretamente da tomada de decisões do projeto e nem é responsável por seus resultados; • Escritório de Apoio a Projetos (Project Support Office - PSO ): Mantem os padrões de gestão de projeto e promove sua utilização. Apoia as tarefas mecânicas dos projetos (como criação e atualização do plano e orçamento do projeto). Não participa diretamente da tomada de decisões do projeto e nem é responsável por seus resultados; • Escritório de Gestão de Projetos (Project Management Office - PMO): Apoia a criação e atualização do plano do projeto definindo custos e prazos. Define gerentes de projetos para todos os projetos da organização. Dá suporte a todos os projetos da organização. Tem força para impor padrões de gestão de projeto. Faz a gestão do plano de carreira dos gerentes de projeto. Não participa diretamente da tomada de decisões do projeto e nem é responsável por seus resultados; • Escritório de Ger. de Programas (Program Management Office - PrgMO): É responsável pelo gerenciamento de programas. A vida útil do Escritório de Gerenciamento de Programas é limitada ao final do programa. Quando o programa acaba, o escritório é dissolvido e seus profissionais realocados. Fornece conhecimento sobre todo o andamento do programa e faz a vinculação entre os projetos do programa. Suas responsabilidadessão mais próximas ao de um PSO (apoio e aconselhamento aos gerentes dos projetos que compõem o programa). Não participa diretamente da tomada de decisões do projeto e nem é responsável por seus resultados; • Escritório de Responsável por Projeto (Accountable Project Office - APO): Este é o modelo mais tradicional de Escritório de Projeto. Assume toda a responsabilidade pelos objetivos do projeto: qualidade, custos e prazo. Fornece suporte a todos os projetos da organização. Fornece gerentes de projetos para todos os projetos da organização. É responsável pelos gerentes de projeto e recursos de apoio. Participa diretamente da tomada de decisões do projeto e é responsável pelos resultados, sejam eles positivos ou negativos. Segundo o PMI (2004) o Escritório de Gerenciamento de Programas “faz gerenciamento centralizado de um programa ou programas específicos de modo que o benefício da empresa seja realizado através de compartilhamento de recursos, metodologias, ferramentas e técnicas, e o foco de gerenciamento de projetos de alto nível relacionado”. Na Tabela 2 podemos visualizar os tipos de Escritório de Projetos e suas responsabilidades sobre os projetos (VERZUH, 2005). As estrelas preenchidas indicam 49 responsabilidade total, as estrelas vazadas indicam participação na atividade com responsabilidade parcial e onde não há estrelas representa que não há responsabilidade sobre o item em questão. Por exemplo, com relação à definição e manutenção de padrões de gerenciamento de projetos, todos os cinco tipos de Escritório de Projetos são totalmente responsáveis. Servir como mentor dos gerentes de projetos aconselhando nos momentos necessários é uma responsabilidade parcial do Escritório de Projetos CE e responsabilidade total dos demais tipos de escritórios. Já a definição e fornecimento de gerentes de projetos para os projetos da organização é uma responsabilidade parcial do Escritório de Gerenciamento de Projetos e responsabilidade total de Escritório Responsável por Projeto. Este quesito não faz parte da responsabilidade dos demais tipos, e assim por diante. Tabela 2: Responsabilidade x Participação segundo VERZUH (2005) Fonte: Adaptado de Patah e Carvalho (2002) Segundo DINSMORE (1998) são cinco diferentes níveis. O Nível 1 chama-se Autonomous Project Team, são times individuais criados para cada projeto e sem aproveitamento nenhum de conhecimentos gerados em projetos anteriores. O nível 2 chama- se Project Support Office, ele oferece suporte a vários projetos ao mesmo tempo, esse nível oferece todo tipo de suporte e gerencia custos, porém não é responsável pelo sucesso do projeto. O nível 3 é o Project Management Center of Excellence e é definido como o ponto de encontro para perícia, ou seja, ele controla e coordena o andamento dos projetos. O nível 4 é o Program Project Office, nessa fase o EP já identifica os programas e passa a gerenciá-los dessa forma, tendo então um gerente por programa e não apenas por projeto. O nível 5 chama- se Chief Project Office e cuida e gerencia o portfólio de projetos e se envolve nas decisões de 50 negócio que resultam em novos projetos, é considerado pelo autor o nível de maior responsabilidade pelos projetos. DINSMORE (1998) e VERZUH (2005) classificam seus níveis de EP de acordo com as missões ou objetivos dos mesmos. Para DINSMORE (1998) estes objetivos variam desde a disseminação de uma metodologia comum de Gestão de Projetos e do suporte em documentações, até a gestão do negócio a partir de uma eficiente gestão de portfólio de projetos. VERZUH (2005), embora utilize outras denominações, apresenta também um aumento na complexidade dos objetivos a serem realizados pelas diferentes categorias. Ambas as classificações contam com cinco níveis de EP. A impressão que estes dois autores passam é que o EP ocuparia uma posição de staff na estrutura organizacional e que cumpriria diferentes objetivos, dependendo da necessidade apresentada pelos setores funcionais e pelos níveis hierárquicos estratégico, tático e operacional. DINSMORE (1999) concebeu tipologia de PMOs que apresenta algumas semelhanças e alguns pontos alternativos, sendo estes os modelos mais aceitos e divulgados atualmente: • Equipe Autônoma de Projetos (Authonomous Project Team) – APT: neste caso a responsabilidade pelo gerenciamento, rateio de custos e resultado do projeto reside na figura dos executores e gerente do próprio projeto. A metodologia e a prática de gestão surgem a partir de conhecimento e experiência adquiridos pelos líderes, e, dessa forma, a organização encontra-se desobrigada a fornecer apoio. • Project Support Office – PSO: esta unidade fornece assistência sob a forma de indicação de boas práticas e ferramentas (apoio administrativo e técnico) durante as cinco fases do projeto. Dado o caráter de “assessoria” – mesmo que interna, os recursos envolvidos nestas atividades são rateados entre os projetos de acordo com a utilização destes serviços e os resultados não são de responsabilidade do EP. • Project Management Center of Excellence – PMCOE: é o centro de excelência em gerenciamento de projetos, ou seja, concentra toda a informação, experiência e metodologia, sendo responsável por guardar e disseminar todo esse conhecimento interno e trazer novas tendências externas. Tem seus custos alocados à organização como um todo já que não “enxerga” os projetos separadamente. Ao mesmo tempo o PMCOE promove e divulga os benefícios da gestão de projetos não se tornando, porém, responsável pelo resultado dos projetos. • Program Management Office – PrgMO: sua função pode ser resumida pela coordenação dos gerentes dos projetos da organização sendo, portanto, responsável por seus resultados. O escritório prioriza e administra os projetos mais significativos para a empresa e fornece apoio pontual aos demais. Assim, pode-se considerar que o PrgMO alia as funções do PMCOE e do PSO requerendo, para tanto, elevado poder e autonomia garantidos pelos altos escalões executivos da empresa. 51 • Chief Project Office – CPO: modelo de PMO com a maior responsabilidade já que atua na alimentação e gestão do portfólio de projetos da empresa. Isto significa que o CPO não só seleciona os projetos como também tem total responsabilidade sobre os projetos ao administrá- los desde sua iniciação até seu encerramento. Dessa forma o escritório alia as práticas e conhecimento comuns ao PrgMO (gerenciamento, priorização de recursos, interface junto a stakeholders, padronização, disseminação de metodologia e competências, etc) e ainda serve como instrumento de aplicação estratégica ao “filtrar” os projetos de acordo com o planejamento estratégico da organização. Tabela 3: Responsabilidade dos EP's. FUNÇÕES DO GERENCIAMENTO DE PROJETOS APT PSO PMCOE PrgMO CPO Prazo EXE APO EDU SUP RES Escopo EXE APO EDU SUP RES Custos EXE APO EDU SUP RES Qualidade EXE APO EDU SUP RES Riscos EXE APO EDU SUP RES Suprimentos EXE APO EDU SUP RES Comunicações EXE APO EDU SUP RES Recursos Humanos EXE APO EDU SUP RES Integração EXE APO EDU SUP RES Responsabilidade por Múltiplos Projetos APO ART COO RES Consistência do GP em toda a Organização APO ART RES Desenvolvimento da Competência em GP ART/PRO COO RES Alinhamento das Estratégias de Negócio com os Projetos ART Acompanhamento dos Projetos em Âmbito Empresarial EXE EXE: Executa; APO: Apóia; EDU: Educa; ART: Articula; PRO: Promove; SUP: Supervisiona; COO: Coordena; RES: Responsabilidade Final Fonte: Adaptado de Dinsmore, 1999 2.2.4.6.1 Importância da Posição do Escritório de Projetos na Organização O Escritório de Projetos é uma espécie de unidade (departamento ou área) criada na estrutura organizacional que ajuda a centralizar e padronizar as informações dos projetos da organização. Suas responsabilidades de são definidas de acordo com o tipo de estrutura organizacional e variam de acordo com os objetivos da organização. Um Escritório de Projetos pode estar posicionado em diversos pontos na estrutura organizacional. Uma organização pode utilizar um ou mais tipos de escritórios de projeto de 52 acordo com suas necessidades (MANSUR, 2007). A Figura 7 mostra um exemplo de Escritório Coorporativo de Projetos criado entre a presidência e as diretorias de uma organização. Figura 7: Escritório Corporativo de Projetos Fonte: Adaptado de MANSUR (2007) A Figura 8 mostra um exemplo de Escritório Divisional de Projetos criado abaixo da Diretoria de Tecnologia para atender os projetos das gerencias de Operações e Desenvolvimento. Figura 8: Escritório Divisional de Projetos Fonte: Adaptado de MANSUR (2007) Na Figura 9 temos um exemplo de Escritório Setorial de Projetos criado abaixo da Gerência de Operações para atender dois departamentos: Suporte e Produção. 53 Figura 9: Escritório Setorial de Projetos Fonte: Adaptado de MANSUR (2007) Já na Figura 10 temos um exemplo de Escritório de Projetos Departamental criado abaixo do departamento de Suporte para concentrar os projetos das áreas de Suporte de Micros, Suporte de Redes e Servidores. Figura 10: Escritório Departamental de Projeto Fonte: Adaptado de MANSUR (2007) Após a aprovação por parte do(s) patrocinador(es) e stakeholders o EP começa a ser efetivamente implementado no órgão e passa a introduzir diversas mudanças internas. A 54 maneira como as pessoas efetuam suas tarefas é modificada, e isso faz surgir diversas barreiras para o EP. Com base nisso, MANSUR (2007) afirma que para alavancar essas mudanças culturais na empresa, a implementação do EP deve ser realizada em etapas. Essas etapas seguem descritas: − 1ª etapa: o EP coordena o esclarecimento, para toda a empresa, da situação atual, da situação futura e as causas da empresas para efetuar as mudanças; − 2ª etapa: os primeiros passos são introduzidos para a padronização do gerenciamento de projetos; − 3ª etapa: começam a ser realizados pelo EP treinamentos fundamentais de gerenciamento de projetos; − 4ª etapa: é realizada uma compilação de documentos padronizados para os processos; − 5ª etapa: o EP é oficializado como suporte para a metodologia de gerenciamento de projetos; − 6ª etapa: são disponibilizados pelo escritório os serviços de coaching para os gerentes de projetos; − 7ª etapa: são introduzidas, periodicamente e aleatoriamente, as auditorias e avaliações de projetos; − 8ª etapa: a liderança no gerenciamento é reforçada pelo EP para garantir que a administração está adotando as novas práticas; − 9ª etapa: ocorre a integração dos sistemas de incentivos e recompensas com o desempenho do gerenciamento de projetos; − 10ª etapa: são treinadas as turmas de projetos focados em processos sofisticados; − 11ª etapa: são absorvidos pelo EP modelos e processos mais sofisticados; − 12ª etapa: as 10ª e 11ª etapas devem ser repetidas para novos processos e aperfeiçoamento dos processos atuais, criando assim um ciclo de melhoria contínua. Já para BRIDGES e CRAWFORD (2001) apud YASBEK (2005), a implementação de um EP deve ocorrer de forma simples, focalizada na geração de valores e estruturada em um plano. Para ocorrer uma implementação bem-sucedida, os autores citam a necessidade do planejamento, comunicação e, principalmente, a cooperação da alta gerência da corporação. Essa última é fundamental para a excelência do EGP. 55 Assim, define-se o EP como sendo a entidade organizacional formalmente estabelecida responsável por definir, uniformizar e defender padrões, processos, métricas e ferramentas; oferecer serviços de gerenciamento, treinamento e documentação; garantir o alinhamento das iniciativas à estratégia organizacional e confeccionar relatórios de progresso e acompanhamento. 56 3. PROCEDIMENTOS DE PESQUISA Segundo ROESCH (1996), a metodologia descreve como o projeto será realizado, tomando por base seus objetivos. Nesta fase serão definidas etapas a serem utilizadas para a sua elaboração e será distinguido entre o delineamento da pesquisa e as técnicas de coleta e análise de dados a utilizar. 3.1 TIPOLOGIA Este estudo se caracteriza por ser de natureza exploratória, sendo que a estratégia de pesquisa adotada foi estudo de caso. Pode-se justificar o uso de métodos qualitativos pelo fato de ele envolver o estudo do processo de gerência de projeto no seu contexto real, com a descrição e a compreensão do estado da arte naquelas situações em que a prática se antecipa à teoria (Yin, 2002). A escolha da utilização do estudo de caso teve objetivo exploratório, para permitir que tanto o pesquisador quanto os stakeholders obtivessem conhecimento sobre o problema. No estudo exploratório, o pesquisador parte de uma hipótese de seu estudo estar nos limites de uma realidade específica, buscando precedentes, maiores conhecimentos, para, em seguida, planejar uma pesquisa descritiva. O estudo exploratório é adequado quando há insuficiência do conhecimento para estabelecer as relações de causa e efeito. Neste caso, vem à tona a questão da existência de uma divisão de programação na Secretaria de Saúde do Estado, porém não é de conhecimento dos gestores a real produção do setor por inexistência de estudos que baseiem a implantação de um escritório de projetos para gerenciá-los, existem várias incógnitas a serem definidas como, por exemplo, a possibilidade de trabalho em grupo dos profissionais que nunca foi explorada visando maior produtividade. Os estudos exploratórios não trabalham com hipóteses a serem testadas, e sim com a busca de mais informações sobre o tema estudado, de acordo com as metas estabelecidas (CERVO e BERVIAN, 2003). Adicionalmente, o estudo teve objetivo de descrever os fatos e dificuldades de uma determinada realidade, assim como aprofundar a sua descrição (TRIVIÑOS, 1987). De acordo com Yin (2001), o estudo de caso é uma pesquisa baseada na experiência que investiga um fenômeno contemporâneo, dentro de um contexto de vida real, especialmente quando os limites entre o fenômeno e o contexto não estão claramente definidos. O caso escolhido foi a implantação de um PMO para gerir uma metodologia de gerenciamento de projetos desenvolvida especialmente para a Secretaria de Estado da Saúde Pública do Rio Grande do Norte. 57 Para a coleta de dados, foram utilizadas as técnicas de análise documental, observação direta e entrevistas focalizadas. A técnica da análise documental é o estudo de documentos do órgão. Documento é toda e qualquer fonte ou base de conhecimento acessível para consulta (PÁDUA, 1997). Os detentores das informações foram selecionados de forma a garantir os dados da pesquisa e do trabalho a ser executado. A observação direta consiste no contato pessoal e estreito do pesquisador com o material de estudo (no caso a Secretaria Estadual de Saúde), permitindo-lhe utilizar seus conhecimentos e experiências como auxiliares no processo de compreensão e interpretação desse material levando-se também em consideração experiências e secretarias e órgãos distintos no âmbito do governo estadual. Com relação à entrevista, ela baseia-se em um roteiro predefinido, tendo o pesquisador liberdade para não abordar algumas questões e incluir outras (LAKATOS e MARCONI, 2005), primeiramente através de entrevistas informais e reuniões de grupo envolvendo relatórios de gestão, e por fim, entrevistas diretas aos gestores imediatos e maiores interessados no objeto fim deste trabalho. Diante deste contexto, o que se pretende com a utilização da abordagem proposta neste projeto de intervenção é prestar um contributo na área de pesquisa em questão através de intervenções reais sob constantes observações empíricas e estudos exploratórias. Objetivamente, pretende-se a produção ou adequação de artefatos de gerenciamento de projetos, para que estes possam auxiliar os profissionais de desenvolvimento de sistemas de informação, e, assim, venham a ter um maior nível de qualidade nos documentos produzidos em todas as fases do desenvolvimento de sistemas. 58 4. INSTITUIÇÃO 4.1 A SECRETARIA DE ESTADO DA SAÚDE PÚBLICA DO RN A SESAP é constituída de 6 coordenadorias e aproximadamente 20 sub- coordenadorias como mostrado na figura 11, das quais possuem inúmeros setores que também geram vários cargos comissionados em suas respectivas chefias de grupo. O objetivo da existência desses cargos de confiança é a manutenção da estabilidade política administrativa e não deixar a administração à mercê de parte do funcionalismo que, embora estáveis e concursados, possam estar comprometidos com outros interesses políticos partidários, sem nenhum compromisso com o bem comum. No entanto, a visão que predomina é de que a confiança em questão é um compromisso individual, de fidelidade do funcionário ao dirigente, e não a confiabilidade e os princípios éticos no trato de assuntos do interesse público. Figura 11: Organograma da SESAP Fonte: PDTI SESAP/2012 59 A expressão confiança para a criação de um cargo público não é nada razoável, uma vez que todo servidor público deveria ser considerado confiável para tratar de assuntos lícitos para o bem da coletividade. Lamentavelmente, acontece a criação de cargos em comissão, simplesmente para atender situações de conveniências. A prática é inerente a este ou aquele partido ou a este ou aquele político. Todos a praticam. Uns mais, outros menos. O que pode ter um agente público de tão grave para confidenciar a um servidor público de confiança, uma vez que o servidor tem um verdadeiro código de conduta em sua legislação própria. Algo que se deve combater não só na SESAP como em todas as esferas municipais, estaduais e federais, a existência dos cargos comissionados que servem como meio de manobra para fixação de acordos feitos como contrapartida aos apoios políticos partidários, muitas vezes sem nenhum critério de competência. Figura 12: Regionalização e Unidades regionais de saúde (URSAP´s) Fonte: PDTI SESAP/2012I URSAP – SÃO JOSÉ DE MIPIBÚ II URSAP – MOSSORÓ III URSAP – JOÃO CÂMARA IV URSAP – CAICÓ V URSAP – SANTA CRUZ VI URSAP – PAU DOS FERROS VII URSAP – GRANDE NATAL VIII URSAP – ASSU 60 4.2 ESTRUTURA ORGANIZACIONAL DA SUININ A SUININ é integrante da Coordenadoria de Planejamento e Controle de Serviços de Saúde – CPCS. São de responsabilidade da SUININ: A política da área de Tecnologia da Informação, incluindo a segurança das informações eletrônicas; o desenvolvimento, contratação e manutenção de soluções de tecnologia e sistemas de informação; a articulação com Hospitais de Saúde e das demais unidades de saúde nos assuntos afetos ao uso da Tecnologia da Informação; a especificação de recursos, implementação, disseminação e incentivo ao uso de soluções de Tecnologia da Informação; e orientação e suporte aos usuários na instalação, configuração e uso de equipamentos, utilização de sistemas, aplicativos e demais serviços na área de Tecnologia da Informação. A fim de ilustrar a sua estrutura organizacional, a figura 13 detalha o organograma da SUININ, com as principais atividades da coordenação, assim como a força de trabalho que compõe cada uma. Figura 13 – Subdivisão da Informática SESAP/RN 5. MODELO ATUAL A SESAP/RN apresenta uma área de projetos ainda não estabelecida, entretanto conta com o trabalho em conjunto de áreas importantes assim como profissionais especializados capazes de resolver os mais diversos problemas relacionados à programação e análise de sistemas, sendo possível assim, trazer resultados positivos para a secretaria. Para tanto, faz-se necessária a criação da equipe de gerenciamento de projetos para dar continuidade aos projetos que, com vida longa pré-estabelecida, possam ser finalizados com sucesso. As dificuldades encontradas no serviço público e a alta rotatividade dos profissionais Fonte: PDTI SESAP/RN 2012 61 aumentam os riscos dos projetos fracassarem. Isso reforça o quão importante é, para o Estado, trabalhar com tecnologia, sempre se aperfeiçoando nos seus produtos e serviços, através da gestão eficaz de seus projetos. É certo que cada instituição ou cada gerente de projetos desenvolva uma metodologia, que tenha a capacidade de mostrar o quê e como deve ser conduzida cada etapa do projeto. Esta metodologia deve ter a amplitude suficiente para auxiliar o gerente em qualquer tipo de projeto dentro da instituição avaliada, e sua flexibilidade deve ser abrangente o suficiente que permitindo adaptações, para que não engesse o projeto, mas que seja uma solução para qualquer problema independente de qual seja a sua natureza. Infelizmente a grande rotatividade não só de profissionais, mas também de Coordenadores e Subcoordenadores oriunda de péssimas condições de trabalho aliados à um Plano de Cargos LC 333/2006 defasado e ineficiente da classe, que não prevê por exemplo progressão por titulação, faz com que “projetos” não sejam concluídos e ainda sejam travadas guerras internas entre gestões voltando a força de trabalho àquilo que melhor corresponde às expectativas de cada gestor. Uma das necessidades prioritárias da SESAP/RN com relação a investimentos em Tecnologia da Informação é a implementação de um sistema gestor hospitalar próprio, no intuito de cobrir toda a rede estadual hospitalar e não apenas algumas unidades da região metropolitana eliminando a grande maioria de softwares proprietários instalados tanto no Nível Central desta Secretaria quanto nos hospitais mencionados. Sendo assim, é urgente a imediata criação de uma divisão de projetos ou sala situação para desenvolvimento de sistemas de saúde que tenha uma organização preparada para este tipo de mudança, onde a rotatividade profissional afetará minimamente o desenvolvimento do projeto que juridicamente constituído seria subordinado diretamente ao Secretário Estadual de Saúde atual para fins de mudanças de escopo e alterações nos cronogramas dos projetos, atualmente a SESAP está organizada como descrito na Figura 11. O relatório de auditoria organizacional do TCE(2013) destaca a localização inadequada da área de TI na estrutura organizacional da SESAP, consequentemente afetando a futura divisão de projetos e o PMO previsto. Ainda segundo o mesmo documento, verifica- se que o atual posicionamento da TI, como uma subcoordenadoria (Subcoordenadoria de Informação e Informática - SUININ) da Coordenadoria de Planejamento e Controle de Serviço de Saúde, dificulta a execução de suas atividades, não permitindo uma atuação independente e nem proporcionando a autoridade necessária à execução das suas atribuições, e destaca ainda que, O organograma da SESAP evidencia claramente que a SUININ possui, 62 ainda, uma posição operacional dentro da SESAP, desalinhada com a alta direção. Suas ações são apenas reativas, não possuindo ainda atuações significativas a nível estratégico. Toda esta situação acarreta o comprometimento do apoio da TI aos processos gerenciais e operacionais. Desta forma, os serviços de TI não contribuem de forma significativa nem a nível estratégico e nem a nível operacional, acarretando falhas no apoio desta aos processos gerenciais, como a geração de indicadores, e falhas nos processos operacionais, como os processos de gestão hospitalar. A auditoria do TCE (2013) então expõe que esta situação é resultado da visão limitada dos gestores em relação a TI e do desconhecimento desta área como estratégico para a instituição. 6. MODELO PROPOSTO Uma adequação organizacional proporcionaria uma maior integração, centralizaria as decisões e ações gerenciais da TI, facilitando o seu planejamento. Além disso, forneceria à TI a autoridade e independência necessárias à realização das suas atividades. Melhoraria, também, os seus processos operacionais, principalmente no que diz respeito aos processos destinados a apoiar as unidades hospitalares. Isto porque atuando de maneira estratégica, a TI deveria atuar de forma planejada, contribuindo para os objetivos organizacionais. Nos últimos meses não só a SUININ como a própria SESAP tem enfrentado situações tão adversas que foram deixadas de lado todas as diferenças políticas no que tange à qualidade dos serviços prestados, e em consequência foram nomeados diversos tecnocratas para tentar solucionar problemas graves de gestão na saúde do Estado. Com isso houve a oportunidade de profissionalizar o setor de desenvolvimento de sistemas em TI apresentando a proposta final deste trabalho aos gestores atuais para a criação e solidificação de um Escritório de Projetos para acompanhamento e evolução de trabalhos planejados como citado anteriormente, onde um desses trabalhos contempla o Sistema Gestor Hospitalar Estadual a ser desenvolvido pela equipe de projetos da SESAP, o qual será objeto de aplicação desta metodologia proposta. O projeto contemplará unidades de todo território norte-rio-grandense, separado inicialmente por microrregiões em seguida por município, primeiramente haverá uma aplicação inicial na VII Unidade de Saúde ou Nível Central na Região Metropolitana, posteriormente o Sistema Gestor Hospitalar, produto final deste projeto será aplicado também nas demais Unidades Regionais de Saúde. 63 7. DESENVOLVIMENTO 7.1 APLICAÇÃO E CICLO DE VIDA DO PROJETO Como foi descrito anteriormente o Guia PMBOK divide a gestão processos em cinco grupos de processos: processos de iniciação, processos de planejamento, processos de execução, processos de controle e processos de encerramento. Essas foram as fases usadas na metodologia inicial proposta (APENDICE A). Figura 14: O ciclo de vida do projeto subdividido em fases ou grupos de processos característicos. Fonte: VARGAS (2009, p29) Segundo VARGAS(2009) “as fases do ciclo de vida do projeto dependem, intimamente da natureza do projeto. Um projeto é desenvolvido a partir de uma ideia, progredindo para um plano, que por sua vez é executado e concluído.” Como mostrado por VARGAS(2009) na figura 14, genericamente o ciclo de vida de um projeto pode ser dividido em fases características. A partir de agora serão listadas todas as fases do ciclo de vida da metodologia, bem como seus processos. Todas as atividades listadas a seguir, estão acompanhadas de suas respectivas descrições, contudo os modelos dos documentos gerados ficarão a cargo do Gerente de Projetos durante o desenvolvimento do projeto de intervenção, documento final desta proposta. 64 Na tabela 4 pode-se observar a metodologia final contendo todos os processos considerados essenciais para compor a documentação do projeto, na proposta inicial foram utilizados apenas 20 processos e no decorrer da execução foi necessária adequação da metodologia com o perfil atual encontrado na SESAP/RN, algumas características do órgão “forçou” a inclusão de mais alguns processos que no decorrer deste capítulo serão melhor detalhados. Ao final 29 (vinte e nove) processos do Guia PMBOK foram diretamente utilizados e mais 3 (três) outros processos foram alocados em documentos sigilosos do projeto que não compõem a metodologia mas funcionam como ativos processuais organizacionais para ajudar a traçar o perfil do órgão. Tabela 4: Processos utilizados (negrito) na metodologia dentre os disponíveis no PMBOK 2013 INICIAÇÃO PLANEJAMENTO EXECUÇÃO MONIT. & CONTROLE ENCERRAMENTO Desenvolver o Termo de Abertura do Projeto Desenvolver o Plano de Gerenciamento do Projeto Orientar e Gerenciar o Trabalho do Projeto Monitorar e Controlar o Trabalho do Projeto Encerrar o Projeto ou Fase Identificar as Partes Interessadas Planejar o Gerenciamento do Escopo Mobilizar a Equipe do Projeto Realizar o Controle Integrado de Mudanças Encerrar as Aquisições Coletar os Requisitos Desenvolver a Equipe do Projeto Validar o Escopo Definir o Escopo Gerenciar a Equipe do Projeto Controlar o Escopo Criar a Estrutura Analítica do Projeto Realizar a Garantia da Qualidade Controlar o Cronograma Planejar o Gerenciamento do Cronograma Gerenciar as Comunicações do Projeto Controlar o Orçamento Definir as Atividades Conduzir as Aquisições Controlar a Qualidade Sequenciar as Atividades Gerenciar o Envolvimento das Partes Interessadas Controlar as Comunicações Estimar os Recursos das Atividades Controlar os Riscos Estimar a Duração das Atividades Controlar as Aquisições Desenvolver o Cronograma Controlar o Envolvimento das Partes Interessadas Planejar o Gerenciamento dos Custos Estimar os Custos Determinar o Orçamento Planejar o Gerenciamento da Qualidade Planejar o Gerenciamento dos Recursos Humanos Planejar o Gerenciamento das Comunicações Planejar o Gerenciamento das Partes Interessadas 65 Planejar o Gerenciamento das Aquisições Planejar o Gerenciamento dos Riscos Identificar os Riscos Realizar a Análise Qualitativa dos Riscos Realizar a Análise Quantitativa dos Riscos Planejar a Resposta aos Riscos Fonte: O próprio autor, 2013 7.1.1 Iniciação 7.1.1.1 Proposta Inicial Na fase de iniciação seriam detalhados os benefícios e os resultados esperados, essas informações neste primeiro momento estariam contidas de forma macro no Termo de Abertura de Projeto – TAP, posteriormente na fase de planejamento essas informações seriam apuradas. No modelo inicial proposto após o recebimento do projeto é feita uma verificação por parte dos responsáveis a respeito da necessidade do projeto para a organização através de uma analise de viabilidade, não sendo aprovado esse projeto é arquivado, caso contrário é elaborada uma proposta para analise dos stakeholders 7 . O registro dos stakeholders seria feito em paralelo com a proposta do projeto, como mostra a figura 15, adotando assim essa abordagem visando agilizar os processos nessa metodologia. Após a aprovação da proposta seria elaborado um contrato ou um documento para formalizar a existência do projeto, logo em seguida elaborado o Termo de Abertura de Projeto. 7 Stakeholder é qualquer pessoa ou organização que tenha interesse ou seja afetado pelo projeto. 66 Figura 15 - Processos da fase de iniciação inicialmente proposta Fonte: produção do próprio autor, 2012 7.1.1.2 Aplicação e Proposta Final A proposta inicial de “Projetos Contratados” e “Projetos Próprios” foi realmente interessante no tocante à relevância dada a cada projeto com relação à aplicação final, visto à necessidade de se obter um resultado satisfatório tanto para projetos próprios, originados especificamente pela SUININ, quanto para projetos oriundos de demandas externas, precisava-se dar a importância real a cada projeto ainda que de interesse divergente da gestão diretamente ligada ao escritório de projetos. Uma mudança básica ocorreu na nomenclatura dos processos que passaram a se chamar “Demandas Internas” e “Demandas Externas”. A tabela 5 mostra os processos contidos na iniciação, suas entradas, saídas e ferramentas utilizadas após aplicação e correção constante da metodologia inicial proposta: 67 Tabela 5: Processos contidos na iniciação da metodologia com suas entradas, saídas e ferramentas PROCESSO ÁREA ENTRADAS FERRAMENTAS SAÍDAS Identificar Interessados Partes Interessadas Termo de Abertura do Projeto Análise de Partes Interessadas Registro das Partes Interessadas Documentos de Aquisição Opinião Especializada Fatores Ambientais do Órgão Reuniões Ativos de Processos Organizacionais Elaborar TAP Integração Declaração do Trabalho do Projeto Opinião Especializada Termo de Abertura do Projeto Business Case Técnicas de Facilitação Contrato Fatores Ambientais do Órgão Ativos de Processos Organizacionais Fonte: Adaptado de PMBOK, 2013 Com relação à análise prévia da necessidade do projeto avaliada por analistas, programadores e gestores diretos viu-se igualmente importante, visto às diversas complexidades de sistemas que de uma forma ou de outra teriam de ser desenvolvidos, para tanto havia um estudo de viabilidade do sistema juntamente com o impacto gerado pelo mesmo dentro do cronograma de projetos já existentes, considerando ou não, assim, a sua aprovação e posterior criação ou modificação de escopo de projeto pré-existente. Após a aprovação do projeto pela equipe de projetos, o gestor se reunia com os analistas para formalizar uma proposta a ser enviada aos gestores imediatos para análise de viabilidade baseado no uso de recursos e demanda de pessoal juntamente com tempo necessário para implementação, um ciclo se criava para garantir que a proposta seria analisada posteriormente sempre que houvesse uma negativa. Na proposta inicial a ideia seria sair da reunião de análise de viabilidade já com um “contrato” pronto para que o gestor imediatamente redigisse o Termo de Abertura para encaminhar ao Gerente de Projetos. A equipe mostrou posteriormente a necessidade de se conhecer os ativos organizacionais ao mesmo tempo que se criava este contrato, como não era de total conhecimento do gestor que participava dessas reuniões para análise de viabilidade foi decidido que a formalização da existência do projeto seria feita após a reunião juntamente com membros da equipe assim redigindo o contrato e atualizando os ativos organizacionais, informações indispensáveis. Os ativos de processos organizacionais incluem qualquer ou todos os ativos relacionados a processos, de quaisquer ou todas as organizações envolvidas no projeto que podem ser usados para influenciar o sucesso do projeto. Estes ativos de processos incluem 68 planos formais e informais, políticas, procedimentos e diretrizes. Incluindo também as bases de conhecimento das organizações, como lições aprendidas e informações históricas. Por exemplo, cronogramas terminados, dados sobre riscos e dados de valor agregado. Normalmente, a responsabilidade por atualizar os ativos organizacionais é dos membros da equipe de projeto. Os ativos de processos organizacionais podem ser agrupados em duas categorias: 1. Processos e procedimentos; 2. Base de conhecimento corporativo. Exemplos de Processos e procedimentos da organização para realizar o trabalho:  Processos organizacionais padrão, como normas, políticas, ciclos de vida padrão do produto e do projeto, e políticas e procedimentos de qualidade;  Diretrizes padronizadas, instruções de trabalho, critérios de avaliação de propostas e critérios de medição de desempenho;  Modelos de documentos;  Diretrizes e critérios para adequação do conjunto de processos padrão da organização para satisfazer às necessidades específicas do projeto;  Requisitos de comunicação da organização;  Requisitos ou diretrizes para encerramento do projeto;  Procedimentos de controles financeiros;  Procedimentos de gerenciamento de problemas e defeitos e acompanhamento de itens de ação  Procedimentos de controle de mudanças, inclusive os passos para modificação das normas, políticas, planos e procedimentos oficiais da empresa – ou quaisquer documentos do projeto – e como essas mudanças serão aprovadas e validadas;  Procedimentos de controle de riscos, inclusive categorias de risco, impacto e definição de probabilidade e matriz de probabilidade e impacto;  Procedimentos para aprovar e emitir autorizações do trabalho. 69 Exemplos de Base de conhecimento corporativo da empresa para armazenar e recuperar informações:  Banco de dados usado para coletar e disponibilizar os dados de medição de processos e produtos;  Arquivos do projeto;  Base de conhecimento de informações históricas e lições aprendidas;  Banco de dados de gerenciamento de problemas e defeitos contendo o andamento de problemas e defeitos, informações de controle, resolução de problemas e defeitos e resultados de itens de ação;  Base de conhecimento de gerenciamento de configuração contendo as versões e as linhas de base de todas as normas, políticas, procedimentos oficiais da empresa e quaisquer documentos de projetos;  Banco de dados financeiro contendo informações como horas de mão-de-obra, custos incorridos, orçamentos e estouros nos custos do projeto. Finalizado o documento formal definindo a existência do projeto juntamente com a equipe, o gestor passa a redigir ao seu modo o Termo de Abertura do Projeto, também chamado Project Charter é o documento que autoriza formalmente o projeto. Ele designa o gerente e concede a este a autoridade para utilizar os recursos da organização na execução das atividades do projeto. Na construção do termo de abertura do projeto foram abordados: requisitos que satisfazem as necessidades do cliente, objetivos do projeto, propósito ou justificativa do projeto (Descrevendo o propósito ou justificativa do projeto detalhando objetivos mensuráveis), restrições e limites (Relacionando as restrições do projeto, ou seja, limitação aplicável a um projeto, a qual afetará seu desempenho, limitações reais como orçamento, recursos, tempo de alocação) stakeholders do projeto e os seus papéis, reponsabilidades e expectativas, identificação do gestor do projeto e nível de autoridade do gerente, cronograma dos marcos do projeto, premissas, ou pressupostos, organizacionais (fatores considerados verdadeiros, reais ou certos como por exemplo a disponibilidade do interlocutor para testes e treinamentos), restrições organizacionais (fatores que limitam as opções da equipe), investimento (orçamento preliminar, incluindo as principais entradas e saídas financeiras do projeto com o valor presente líquido calculado), riscos, descrição do(s) subproduto(s) 70 identificado(s) e identificações de marcos assim como os critérios de sucesso do projeto, descrevendo de forma mensurável o que constitui o sucesso do projeto e quem decide se o projeto foi bem sucedido, permitindo assim responder a questões como: O que deve ser feito para atingir o objetivo do projeto? Como deve ser feito? Quem o vai fazer? Quando deve ser feito? Num primeiro momento foram documentadas apenas as informações relacionadas ao resumo das condições do projeto explicando a situação atual juntamente com as necessidades; foram definidos o nome do gerente do projeto, suas responsabilidades e sua autoridade, as necessidades básicas do trabalho à ser realizado assim como as descrições do projeto e do produto, um cronograma básico e uma estimativa inicial assim como as necessidade iniciais relacionadas à recursos humanos, necessidade de suporte, controle e gerenciamento das informações do projeto. Posteriormente após a fase de iniciação este documento será complementado com a declaração do escopo do projeto, um outro documento que especificará e abrangerá todos os itens destacados anteriormente. Posteriormente à criação e entrega do Termo de Abertura do Projeto ao Gerente de Projetos, na proposta inicial haveria o avanço já para a segunda fase do projeto como descrito no PMBOK 4 (2008), porém, visando a constante atualização do documento final deste estudo foi decidido atualizar a metodologia para a versão 5 do PMBOK, lançada em 2013, o qual informa que a detalhada descrição dos envolvidos no projeto, stakeholders, seja realizada ainda na fase de iniciação logo após a criação do TAP pelo gestor. Analisando-se esta melhoria viu-se a necessidade de mais uma reunião da equipe com o gerente e o gestor imediato para definição destes que seriam as partes interessadas no projeto, um documento seria gerado ao final desta reunião que seria denominado de Registro das Partes Interessadas. O modelo final proposto para a fase de iniciação está detalhado na figura 16. 71 Figura 16: Metodologia Final Proposta – Fase de Iniciação. Fonte: O próprio autor, 2014. 7.1.2 Planejamento 7.1.2.1 Proposta Inicial No planejamento inicialmente previsto, o foco principal seria a elaboração do Plano de Gerenciamento do Projeto, que envolve algumas etapas preliminares que após consolidação iria conter uma visão geral do ciclo de desenvolvimento do projeto incluindo cronograma com as principais previsões, riscos identificados, recursos e investimentos necessários (análise dos custos), plano de comunicações e critérios de aceitação dos produtos (controle de qualidade). Na metodologia inicial proposta (figura 17), o planejamento seria iniciado com o estabelecimento dos métodos de comunicação do projeto tanto externo como internos, visando uma maior agilidade no que diz respeito à informações relevantes ao projeto, logo depois iniciaria a coleta e analise dos requisitos dando origem à confecção da declaração do escopo do projeto, que acontece em simultaneidade com a identificação dos riscos, dessa forma à medida que o escopo fosse elaborado os riscos seriam identificados. Com a parte de delimitação do projeto pronta seria feita a Estrutura Analítica de Projeto – EAP ou Work Breakdown Structure – WBS, ela iria demonstrar graficamente a decomposição do projeto. Sua elaboração seria feita pela Equipe do Projeto. Na metodologia proposta não seria criado um plano de contingência, mas adotada estratégias de respostas de contingência que seriam usadas somente caso de certos eventos viessem a ocorrer. 72 Uma vez terminada a etapa estratégica de resposta de contingência, o plano de gerenciamento de projetos entraria na sua fase crucial do planejamento, um bloco de processos seriam feitos simultaneamente visando à criação do cronograma, ao mesmo que tempo que seriam planejados os recursos humanos e a qualidade e, estimados os custos a confecção do cronograma seria finalizada, visando o melhor entendimento dos custos e da mão de obra empregada. A partir deste momento seria utilizado o Gráfico de Gantt para definir o cronograma das atividades, nele haveria inclusive as alocações de recursos e através dele seriam feitas as comunicações das atividades do projeto aos stakeholders assim como o monitoramento e gerência das atividades. Com o Gráfico de Gantt em mãos, o planejamento do processo passaria pela mais importante e decisiva fase, onde seriam identificadas as sequências de atividades críticas e consequentemente o caminho crítico, que será o grande vilão no caso de uma falha no projeto, qualquer delay gerado pelo caminho crítico influenciaria gravemente no cronograma do projeto protelando todas as atividades sequenciais. Nos projetos, algumas atividades são flexíveis, em relação ao seu início e término, e outras não o são. As atividades, que não têm margem de flexibilidade, são chamadas de atividades críticas. A sequência dessas atividades, no cronograma do projeto é o caminho crítico do projeto. Com todos os dados anteriores em mãos, seria determinado o orçamento demonstrando todos os requisitos financeiros do projeto, nele conteria os gastos totais com o projeto e seus possíveis incrementos. A reunião de todos os processos anteriores daria origem ao plano de gerenciamento do projeto. Figura 17 - Processos da fase de planejamento inicialmente proposta Fonte: O autor, 2012 73 Com o Plano do Projeto aprovado, o gerente do projeto iniciaria a fase de execução, conforme planejamento proposto e aprovado no Plano de Gerenciamento do Projeto. 7.1.2.2 Aplicação e Proposta Final Na análise dos processos da fase de planejamento do Guia PMBOK foram analisados e retirados alguns processos, ficando apenas aqueles necessários na visão do autor baseado no perfil da SESAP, com o objetivo de agilizar a fase de planejamento, a tabela 6 detalha todos os processos utilizados na metodologia nesta fase incluindo suas entradas, saídas e ferramentas utilizadas. Tabela 6: Processos contidos no planejamento da metodologia com suas entradas, saídas e ferramentas PROCESSO ÁREA ENTRADAS FERRAMENTAS SAÍDAS Planejar Gerenciamento das Comunicações Comunicações Plano de Gerenciamento do Projeto Análise de Requisitos da Comunicação Plano de Gerenciamento das Comunicações Registros das Partes Interessadas Tecnologia das Comunicações Atualização dos Documentos do Projeto Fatores Ambientais da Empresa Modelos de Comunicações Ativos de Processos Organiz. Métodos de Comunicação e Reuniões Coleta e Análise de Requisitos Escopo Plano de gerenciamento do escopo Entrevistas Documentação dos requisitos Plano de gerenciamento dos requisitos Grupos de discussão Matriz de rastreabilidade dos requisitos Plano de gerenciamento das partes interessadas Oficinas facilitadas Termo de abertura do projeto Técnicas de criatividade em grupo Registro das partes interessadas Técnicas de tomada de decisão em grupo Questionários e pesquisas Observações Protótipos Benchmarking Diagrama de contexto Análise dos documentos Definir Escopo Escopo Plano de gerenciamento do projeto Opinião Especializada Declaração do escopo do projeto Termo de abertura do projeto Análise de produto Atualizações dos Documentos do projeto Documentação dos requisitos Geração de alternativas Ativos de processos organiz. Oficinas facilitadas Planejar Aquisições e Contratações Aquisições Plano de gerenciamento do projeto Análise de fazer ou comprar Plano de gerenciamento das aquisições Documentação dos requisitos Opinião especializada Declarações do trabalho das aquisições Registro dos riscos Pesquisa de mercado Documentos de aquisição Requisitos de recursos das atividades Reuniões Critérios para seleção de fontes 74 Cronograma do projeto Decisões de fazer ou comprar Estimativas de custos das atividades Solicitações de mudança Registro das partes interessadas Atualizações dos Documentos do projeto Fatores ambientais da empresa Ativos de processos organizacionais Planejar Gerenciamento do Escopo Escopo Plano de gerenciamento do projeto Opinião Especializada Plano de gerenciamento do escopo Termo de abertura do projeto Reuniões Plano de gerenciamento dos requisitos Fatores ambientais da empresa Ativos de processos organizacionais Analisar e Identificar Riscos Riscos Plano de gerenciamento dos riscos Revisões de documentação Registro dos riscos Plano de gerenciamento dos custos Técnicas de coleta de informações Plano de gerenciamento do cronograma Análise de listas de verificação Plano de gerenciamento da qualidade Análise de premissas Plano de gerenciamento dos recursos humanos Técnicas de diagramas Linha de base do escopo Análise de forças, fraquezas, oportunidades e ameaças - SWOT Estimativas de custos das atividades Opinião Especializada Estimativas de duração das atividades Registro das partes interessadas Documentos do projeto Fatores ambientais da empresa Ativos de processos organizacionais Criar EAP Escopo Plano de gerenciamento do projeto Decomposição Linha de base do escopo Declaração do escopo do projeto Opinião Especializada Atualizações dos Documentos do projeto Documentação dos requisitos Fatores ambientais da empresa Ativos de processos organizacionais Elaborar Cronograma Tempo Plano de gerenciamento do cronograma Análise de rede do cronograma Linha de base do cronograma Lista das atividades Método do caminho crítico Cronograma do projeto Atributos das atividades Método da corrente crítica Dados do cronograma Diagramas de rede do cronograma do projeto Técnicas de otimização de recursos Calendários do projeto Requisitos de recursos das atividades Técnicas de criação de modelos Atualizações do Plano de gerenciamento do projeto Calendários dos recursos Antecipações e esperas Atualizações dos Documentos do projeto Estimativas de duração das atividades Compressão de cronograma Declaração do escopo do projeto Ferramenta de cronograma Registro dos riscos Designações do pessoal do projeto 75 Estrutura analítica dos recursos Fatores ambientais da empresa Ativos de processos organiz. Planejar Custos Custos Plano de gerenciamento do projeto Opinião Especializada Plano de gerenciamento dos custos Termo de abertura do projeto Técnicas analíticas Fatores ambientais da empresa Reuniões Ativos de processos organizacionais Planejar Qualidade Qualidade Plano de gerenciamento do projeto Análise de custo-benefício Plano de gerenciamento da qualidade Registro das partes interessadas Custo da qualidade Métricas da qualidade Registro dos riscos As sete ferramentas básicas da qualidade Listas de verificação da qualidade Documentação dos requisitos Benchmarking Plano de melhorias no processo Fatores ambientais da empresa Projeto de experimentos Atualizações dos Documentos do projeto Ativos de processos organizacionais Amostragem estatística Ferramentas adicionais de planejamento da qualidade Reuniões Planejar Recursos Humanos Recursos Humanos Plano de gerenciamento do projeto Organogramas e descrições de cargos Plano de gerenciamento dos recursos humanos Requisitos de recursos das atividades Rede de relacionamentos Fatores ambientais da empresa Teoria organizacional Ativos de processos organizacionais Opinião Especializada Reuniões Determinar Orçamento Custos Plano de gerenciamento dos custos Agregação de custos Linha de base do desempenho de custos Linha de base do escopo Análise de reservas Requisitos de recursos financeiros do projeto Estimativas de custos das atividades Opinião Especializada Atualizações dos Documentos do projeto Bases das estimativas Relações históricas Cronograma do projeto Reconciliação dos limites de recursos financeiros Calendários dos recursos Acordos Ativos de processos organizacionais Desenvolver o Plano de Gerenciamento do Projeto Integração Termo de abertura do projeto Opinião especializada Plano de gerenciamento do projeto Saídas de outros processos Técnicas de facilitação Fatores ambientais da empresa Ativos de processos organizacionais Fonte: Adaptado de PMBOK, 2013 76 7.1.2.2.1 Plano de Gerenciamento do Projeto Segundo o Guia PMBOK, o plano de gerenciamento do projeto integra e consolida todos os planos de gerenciamento auxiliares e linhas de base dos processos de planejamento, incluindo, mas não estando limitado a:  O ciclo de vida selecionado para o projeto e os processos que serão aplicados a cada fase;  Resultados das adequações feitas pela equipe de gerenciamento do projeto;  Como o trabalho será executado para completar os objetivos do projeto;  Um plano de gerenciamento de mudanças que documenta como as mudanças serão monitoradas e controladas; O processo Desenvolver o Plano de Gerenciamento do Projeto tem como objetivo a criação do Plano de Gerenciamento do Projeto, documento que explica a forma como o projeto irá ser gerido, incluindo as ações necessárias para definir, coordenar e integrar todos os planos setoriais (Partes Interessadas, Comunicações, Escopo, Tempo, Custo, Qualidade, Risco, Comunicação, Recursos Humanos e Aquisições) num documento único que permita a gestão eficaz do projeto. Pertencendo à área de conhecimento Gestão da Integração, o processo Desenvolver o Plano de Gerenciamento do Projeto recebe e entrega contributos a numerosos processos das áreas de planejamento e monitoramento e controle. O conteúdo do Plano de Gerenciamento do Projeto é variável em função da área de aplicação e da complexidade do projeto. De acordo com a especificidade ou complexidade do projeto o plano de gerenciamento do projeto deverá ser complementado com os planos setoriais mais detalhados. No caso específico do projeto proposto à SESAP o Plano de Gerenciamento do Projeto será composto pelos seguintes itens anteriormente detalhados:  Apresentação do Projeto (APENDICE C) e Declaração de Escopo (APENDICE D);  Termo de Abertura do Projeto (APENDICE E);  Estrutura Analítica do Projeto (APENDICE F);  Cronograma (APENDICE G);  Planilha de Riscos (APENDICE K);  Plano de Gerenciamento das Comunicações (APENDICE M);  Plano de Gerenciamento de Escopo (APENDICE F); 77  Plano de Gerenciamento de Aquisições (APENDICE L);  Plano de Gerenciamento de Custos e Orçamento (APENDICE I);  Plano de Gerenciamento da Qualidade (APENDICE H);  Plano de Gerenciamento de Recursos Humanos (APENDICE J); O Plano de Gerenciamento do Projeto - PGP é importante para o controle do escopo assim como para manutenção preventiva do controle da qualidade do projeto, é atualizado principalmente pelos processos de planejamento e serve de entrada para praticamente todos os processos. Com ele em mãos a equipe de projeto está pronta para entrar na fase de execução de projetos. Os artefatos assim como todo o processo de criação do PGP, incluindo todos os planos de gerenciamento anteriormente citados serão padronizados segundo VARGAS (2009) onde cada plano de gerenciamento poderá conter, ou não, a depender da metodologia e processos adotados, outros relatórios e gráficos para compor cada documento. Embora não se tenha utilizado explicitamente na fase de Planejamento um processo específico para criação do Plano de Gerenciamento das Partes Interessadas, é exatamente esta atividade que caracteriza a passagem da fase de iniciação para o planejamento. Devido à natureza deste documento, caracteriza-se como estratégico e sigiloso, uma vez que contém todo o mapeamento dos riscos do projeto incluindo posteriores necessidades de comunicação, então para evitar fortes influências dentro da execução do projeto este será um documento particular do Gerente de Projetos e não será especificado na metodologia. 7.1.2.2.2 Plano de Gerenciamento das Partes Interessadas A Análise dos Stakeholders é um processo sistemático de coleta e análise de informação sobre os interesses, objetivos e preferências dos interessados para se mapear os riscos e as necessidades de comunicação do projeto. Resumidamente, as etapas são estas: O primeiro passo é determinar quem pode afetar o projeto. A lista deve ser exaustiva, identificando através de sessões de brainstorming interessados positivos e negativos em post-its de cores diferentes colando-os em seguida em um primeiro flipchart 8 , 2 (duas) ou 3 (três) sessões de 45 (quarenta e cinco) minutos são desejadas, no estudo de caso 8 É um tipo de quadro, usado geralmente para exposições didáticas ou apresentações, em que fica preso um bloco de papéis. Deste modo, quando o quadro está cheio, o apresentador simplesmente vira a folha (em inglês, flip) 78 relatado foram utilizadas duas sessões de 1 (uma) hora e ao final deste período a equipe já tinha em mãos praticamente todos os interessados divididos em positivos e negativos, importante realçar que a lista de interessados deve ser por interesse dependendo do perfil de cada um, para relatar uma entidade ou grupo inteiro como um stakeholder houve a necessidade de classificar cada grupo que possuía independentemente de seus colaboradores a mesma visão ou perfil. O segundo na construção do PGPI passo é identificar os pontos de contato de cada interessado com o projeto. Pessoas que estão realizando o trabalho diariamente têm maior influência do que fornecedores pontuais. Um outro flipchart foi utilizado para o mapeamento dos stakeholders dentro dos quatro quadrantes de influência ou poder (eixo y) e interesse (eixo x) sendo os quadrantes superiores etiquetados como “muito” e os inferiores como “pouco”, ou seja, no quadrante superior esquerdo estarão localizados os opositores, aqueles que tem muito poder e pouco interesse com isso podendo interferir diretamente no projeto, no superior direito os grandes aliados, que além de possuírem muito interesse também tem alto poder de decisão, já no quadrante inferior esquerdo teríamos os “detratores” que possivelmente criarão problemas sucessivos minando o tempo do projeto e no inferior direito os apoiadores que direta ou indiretamente ajudarão a convencer os que tem poder a executar e apoiar o projeto. O terceiro passo é identificar como cada interessado pode ajudar e atrapalhar o andamento do projeto, e quantificar os graus de poder/influência e interesse de cada interessado. Isso pode ser subjetivo obtido a partir do levantamento do comportamento passado ou mais objetivo usando um modelo probabilístico. Para tal usamos um terceiro flipchart contendo o planejamento das respostas. Nele mapearíamos os stakeholders como àqules que precisam de alguma ação para que se altere o status de interesse/poder ou se é preciso apenas acompanhar e monitorar, é neste flipchart que teremos as respostas relacionadas à quais ações naqueles determinados stakeholders inibem, transformam ou potencializam o “aliado”, dependendo do que for feito, por exemplo com o escopo do projeto, se aquela ação traria impactos diretos nos custos, prazos ou riscos do projeto. Ao final teríamos duas planilhas com definições dos impactos das ações para cada interessado. Para sistematizar nossa análise, nossas planilhas continham nomes/cargos dos interessados na primeira coluna, influências positivas na segunda coluna e negativas na terceira. Na quarta coluna colocamos uma nota de 1 a 10 para dimensionar o grau de poder (influência) que cada interessado tem no projeto (10 é o máximo). Na quarta e quinta colunas 79 foram inseridos os graus de interesse (de 0 a 10) no projeto. Nesta tabela de análise pode-se colocar também uma sexta coluna indicando como será tratado cada interessado, ou seja, com relação à monitorar (acompanhar a distância), manter informado (este caso já merece que se formalize a comunicação no Plano de Comunicação), manter satisfeito (além de informado, este nível exige um acompanhamento das expectativas) e gerenciar (nível máximo de acompanhamento, com contato frequente e muita transparência). Como o patrocinador tem poder total sobre todas as etapas do projeto, ele é um stakeholder crítico que deve receber um acompanhamento muito próximo. 7.1.2.2.3 Plano de Gerenciamento das Comunicações O Plano de Gerenciamento das Comunicações - PGCO previamente estabelecido na metodologia inicial proposta mostrou-se muito útil e bem posicionada nesta segunda fase. A comunicação certamente é uma das áreas de conhecimento mais importantes para o GP, senão for a mais importante. Ela representa cerca de 90% do tempo do GP e é o elo de ligação entre as pessoas, as ideias e as informações. Além disso, a maioria dos problemas dos projetos são oriundos de falha de comunicação e existe uma forte correlação entre o desempenho do projeto e a habilidade do GP em administrar as comunicações. Os principais objetivos deste planejamento incluem conectar as diversas partes interessadas apesar de seus diferentes interesses e culturas para atender os objetivos do projeto, fornecer as ligações críticas entre pessoas e informações necessárias para comunicações bem-sucedidas, garantir a geração, disseminação, armazenamento, recuperação e descarte de informações do projeto e manter as partes interessadas “alinhadas”. Então é nesta parte que são elaborados planos de ação definindo reuniões semanais, mensais ou diárias se necessário além das extraordinárias, aqui também serão armazenados alguns dos artefatos inicialmente desenvolvidos para conhecimento de todos os interessados como a Estrutura Analítica do Projeto, o Gráfico de Gantt, Diagrama de Marcos e Percentual Completo das Atividades, em alguns casos apresentando ainda o acompanhamento do orçamento e a arquitetura de acesso do site. Um documento formal de Gerenciamento das Comunicações foi necessário nesta fase do planejamento visto à posição do Escritório de Projetos dentro do órgão para que fossem mostrados todos os documentos que levariam o projeto adiante. Foi priorizado o ato de manter as partes interessadas já definidas bem informadas com relação à disponibilidade de informações, que através de relatórios operacionais e documentos formais criados justamente 80 para suprir esta demanda que não foi prevista na metodologia inicial estarão à disposição dos stakeholders nas diversas fases do projeto mantendo-os cada vez mais interessados, o que não acontecia até a atualização da metodologia. No projeto proposto foi citado apenas a opção de se contar com métodos de comunicação externos e internos, porém durante o este planejamento das comunicações viu-se a necessidade de contar com alguém além do analista de sistemas interno, teríamos um assessor para assuntos hospitalares que por ter natureza específica e já fazer parte do corpo funcional da SESAP, foi decidido juntamente com o patrocinador realocar um profissional na SUININ com esses conhecimentos para ajudar na implementação de regras de negócio futuramente junto ao analista e evitar o acúmulo de atividades em um analista que teria um foco específico alimentado pelo assessor, ganhando celeridade tanto no fornecimento de informações quanto na comunicação em geral com as unidades hospitalares. A partir deste ponto as análises de requisitos eram constantemente registradas e atualizadas no portfólio da SUININ, cedendo informações importantes para o Gerente de Projetos que com a ajuda de um analista de um assessor estaria envolvido completamente na fase de declaração do escopo do projeto, ao mesmo tempo em que o escopo era definido os riscos eram mitigados e listados em uma planilha que, confrontada com o escopo atual, seria de suma importância para o sucesso da execução deste projeto. Para produção do documento de PGCO inicialmente se define quais os processos de comunicação formal que serão utilizados pela SUININ, a princípio foram utilizados apenas e-mails oficiais e comunicações através de memorandos, mas a partir do momento em que toda a equipe de projeto começou efetivamente a exercer suas atividades viu-se a necessidade de abranger estes modelos e muitas outras formas de comunicação foram sendo aceitas e homologadas pelos participantes como publicações no site do projeto, decisões em reuniões, documentos impressos e mensagens instantâneas. Em um segundo momento, no documento acrescentamos todos os tipos de atividades previstos no gerenciamento das comunicações, deveremos detalhar se haverá por exemplo Kick Off Meeting, quais as frequências e que reuniões serão requeridas na metodologia, devendo-se esclarecer os objetivos de cada reunião citando o método de execução, a duração, o local, os envolvidos e o responsável por cada uma delas. 81 A partir deste ponto, os documentos tornam-se opcionais dependendo do perfil do órgão ou empresa, no próximo ponto pode-se cobrar quais itens devem fazer parte das atas de reunião e se estas são obrigatórias ou não, por último vem os relatórios do projeto para acompanhamento da equipe como citado anteriormente, iniciando-se pela exibição da WBS atualizada (APENDICE F). Por fim, o documento deve informar como serão armazenados todos os recursos relacionados à comunicação do projeto, se o ambiente de trabalho contará com um servidor destinado a suportar as características corporativas do órgão, incluindo banco de dados consolidado de projetos, pool de recursos e arquivo de configuração corporativos, ferramentas de gerenciamento de relatórios dinâmicos (Análise de portfólio), bem como definir detalhadamente como será executado o gerenciamento de documentos do projeto. O fechamento do documento segue o padrão proposto por VARGAS (2009), com a alocação financeira para o PGCO, os responsáveis pela administração do plano, a frequência de atualização do mesmo além do registro de alterações e suas descrições feitos pela equipe do projeto juntamente com o aceite final do GP e/ou patrocinador. 7.1.2.2.4 Definindo o Escopo do Projeto A constituição do escopo do projeto foi definida inicialmente pelo Gerente de Projetos como um universo contendo o documento do TAP, a Declaração do Escopo, a WBS e o Plano de Gerenciamento do Escopo. Através do TAP obtido na fase de iniciação, o GP define a declaração do escopo, um documento formal que será utilizado para aprovações e análises de requisitos junto aos patrocinadores do projeto. Também chamado de Scope Statement esta declaração contém informações complementares do TAP no que diz respeito ao time, descrição, objetivo, justificativa, produto, fatores de sucesso, restrições, premissas e principais atividades e estratégias do projeto, além de dar uma previsão do orçamento e do cronograma de marcos e entregas do projeto, é essencial para o sucesso do mesmo, pois, descreve as entregas do projeto e o trabalho necessário para criá-las. Ela é desenvolvida a partir das principais entregas, do termo de abertura, dos requisitos, premissas e restrições. Durante a confecção da Declaração do Escopo, foi definido o nome do Gerente de Projetos responsável e suas atribuições assim como suas limitações relacionadas à “contratações” para compor a equipe de projeto assim como em que esfera sua autoridade abrange, de acordo com o escritório de projetos estabelecido inicialmente pela SESAP. Neste 82 momento também foram convocados todos os servidores atualmente lotados no Nível Central desta secretaria para decidir quem iria compor a equipe de projeto, o patrocinador como Subcoordenador da SUININ decidiu juntamente com o Gerente de Projetos e um cargo comissionado chefe de grupo quais os profissionais ideais para trabalhar em equipe dali em diante. Uma tabela contendo vínculo, nome, cargo e função foi criada para descrevê-los. Uma breve descrição do projeto foi adicionada à declaração do escopo, o projeto seria composto por 13 (treze) subprojetos que teriam posteriormente suas próprias declarações de escopo especificando cada subprojeto, porém não foi detectada a necessidade de recriar o TAP, a WBS e cada plano de gerenciamento específico em separado, apenas do projeto principal. Cada subprojeto teria então seus próprios tópicos dentro de suas próprias declarações como, por exemplo, na declaração de escopo do primeiro subprojeto utilizado como base deste estudo, o objetivo do primeiro subprojeto era simples e direto, implementar o gerenciamento de projetos na SUININ através de um escritório de projetos (PMO), dentro da metodologia estabelecida pela divisão de projetos, em um prazo máximo de 110 dias úteis a partir de setembro de 2013 e com um custo total estimado de R$23.175,00. Uma característica importante da participação do Gerente de Projetos na confecção da Declaração do Escopo era que a metodologia proposta pelo GP definia que esta atividade teria de ser realizada em paralelo à identificação dos riscos, pois considerando todos os possíveis riscos internos e externos, a previsão tanto de gastos quanto de prazos previamente estabelecidos seria alterada em tempo de execução, para que não houvesse tantas solicitações e registros de mudanças durante a fase de execução do projeto pondo em cheque a confiabilidade da metodologia e do sistema a ser implementado. 7.1.2.2.5 Estrutura Analítica do Projeto O conceito de Estrutura Analítica de Projeto (em Inglês, Work Breakdown Structure – WBS) remonta ao tempo em que a Marinha Americana, durante o Projeto Polaris 9 , criou a técnica denominada Program Evaluation Review Technique (PERT). O diagrama PERT, denominado também Diagrama ou Rede de Precedências, vincula e sequencia as atividades do Projeto. Porém, antes de criar a lógica sequencial das atividades, é necessário decompor o Projeto em unidades cada vez menores e mais detalhadas, para que 9 O projeto Polaris foi o primeiro SLBM (Submarine-Launched Ballistic Missile - Míssil Balístico de Lançamento Submarino) liberado pela marinha Norte-Americana. Financiado e desenvolvido por volta dos anos 50 durante a Guerra Fria, tendo como intuito substituir o antigo míssil Regulus, tornou-se uma das mais importantes contribuições bélicas para os EUA desde então. 83 posteriormente se possa estabelecer a rede de precedências. O menor nível da EAP é denominado Pacote de Trabalho. De acordo com o PMBOK 2013 ela representa uma “decomposição hierárquica orientada às entregas do trabalho a ser executado pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas, sendo que cada nível descendente da EAP representa uma definição gradualmente mais detalhada da definição do trabalho do projeto”. Através de uma estrutura semelhante a um organograma, a EAP representa o que deverá ser entregue pelo projeto. Ela permite detalhar quais as entregas que devem ser geradas em função dos objetivos do projeto. No caso específico do projeto de desenvolvimento do sistema de gestão hospitalar estadual foram levados em consideração 3 (três) níveis hierárquicos para a distribuição das entregas da EAP. No primeiro nível as entregas foram organizadas por módulo de desenvolvimento, dentre os quais estão o Gerenciamento do Projeto em si e o módulo de PMO e base de dados, sendo este último objeto de estudo de referência para a aplicação de toda esta metodologia implementada. Ao total existem 14 entregas de primeiro nível, dos quais 13 são módulos do sistema de gestão hospitalar a ser desenvolvido, cada um com sua particularidade na sequência correta de entrega e distribuição. A EAP do projeto (figura 18) foi definida pelo Gerente de Projetos em parceria com os analistas de sistema da SESAP, foi decidido que na EAP estariam exibidos para cada pacote de trabalho os dias demandados, data inicial e final da execução de cada etapa e o percentual total de conclusão de cada pacote. Os pacotes em seus diferentes níveis foram enumerados de forma a sequenciar entregas também em subníveis hierárquicos. A decisão de mostrar todos estes dados na EAP foi tomada pela necessidade dos gestores imediatos e patrocinadores de acompanhar o desenvolvimento do projeto sem que precise efetivamente acessar o cronograma completo, bem mais complexo e com muita informação desnecessária para alguns destes stakeholders.A Estrutura Analítica do Projeto pode ser melhor visualizada no APENDICE F. 84 Figura 18: Estrutura Analítica do Projeto SIGIH/SESAP/RN Fonte: O próprio autor, 2014 7.1.2.2.6 Plano de Gerenciamento do Escopo O Plano de gerenciamento do escopo (PGE) descreve como o escopo será definido, desenvolvido, monitorado, controlado e verificado. Ele é um dos planos auxiliares do plano de gerenciamento do projeto. Deve ser um documento de fácil entendimento para que todas as partes interessadas estejam alinhadas em relação ao escopo do projeto. No PGE proposto, inicialmente deve ser feita a descrição dos processos de gerenciamento de escopo, assim como classificar as mudanças de escopo em níveis de 85 prioridades, classificando-as em 4 (quatro) níveis diferentes para o nosso caso como mostrado em VARGAS(2013): 0 (zero) – Requer uma ação imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador, uma vez que se trata de mudança urgente, de alto impacto no projeto e em outras áreas sobre as quais o gerente de projeto não tem autonomia. 1 (um) – Requer uma ação imediata por parte do gerente do projeto, independente das reuniões de controle previstas devido à urgência, acionando imediatamente o patrocinador no caso de necessidade de autorizações financeiras fora da alçada do gerente de projetos. 2 (dois) – Requer um planejamento da ação através de terceiros ou de equipes que, a princípio, tenham disponibilidade, uma vez que agregam valor ao sucesso do projeto e são urgentes, porém não têm impacto significativo nos custos e nos prazos do projeto. 3 (três) – Podem ser implementadas por terem influência no sucesso do projeto, porém não requerem uma ação imediata por não serem impactantes ou urgentes. Depois de elencados os itens, deve-se definir a frequência de avaliação do escopo do projeto, ou seja, nas reuniões previstas no gerenciamento das comunicações o escopo do projeto deverá ser avaliado com relação a mudanças (figura 19), tais mudanças requerem alocações financeiras para cobrir os gastos na execução do projeto. Com isto o plano deve conter as origens de todas as alocações financeiras para despesas decorrentes de mudanças no escopo do projeto, porém o quantitativo de reservas de contingência deve ser exibido apenas no plano de gerenciamento de riscos. Figura 19: Fluxograma para Controle de Mudanças no Escopo Fonte: Adaptado de VARGAS, 2013. 86 Em seguida a escolha dos administradores do plano de gerenciamento do escopo deve ser exposta em tópico relacionado à administração do PGP que conterá os responsáveis diretos pelo PGP assim como seus suplentes, outro ponto importante a ser citado neste documento é a frequência de atualização deste PGP, deve-se decidir se semanalmente ou mensalmente este PGP será atualizado, de acordo com as reuniões do PGCO. Ao final deste documento são elencadas todas as atualizações e seus responsáveis diretos assim como o registro da descrição de cada mudança, todos organizados em uma tabela de fácil visualização, este PGP vai estar contigo no Plano de Gerenciamento do Projeto ao final da fase de planejamento. 7.1.2.2.7 Plano de Gerenciamento de Riscos O Plano de Gerência de Riscos descreve como a identificação, a análise qualitativa e quantitativa, o planejamento de respostas, a monitoração e o controle do risco será estruturado e realizado ao longo do ciclo de vida do projeto. A necessidade de gerenciar riscos decorre, principalmente, da consciência de existência de fatores, internos ou externos ao projeto, cujo desencadeamento, ao longo do seu ciclo de vida, pode alterar o objetivo do mesmo. A identificação desses fatores ou das suas causas constitui uma das etapas fundamentais de qualquer metodologia de gestão dos riscos. O tipo de risco, a sua probabilidade de ocorrência, ou o seu impacto sobre o projeto variam ao longo do ciclo de vida do mesmo, sendo por isso necessário proceder-se à identificação dos riscos, em todas as suas fases. Como citado anteriormente, o gerenciamento de riscos do projeto em questão foi feito em paralelo à construção do documento de declaração do escopo para que fosse de fácil detecção os maiores riscos e estes pudessem ser evitados através de alterações no escopo do projeto devido a estas informações. O PGR é um documento realmente essencial, mas por opção da equipe do projeto este será mantido apenas para consulta das chefias e subcoordenações interessadas para conhecimento total do teor dos riscos, o documento formal a ser utilizado e publicado no projeto será somente uma planilha resumida de riscos criada durante a edição do Plano de Gerenciamento de Riscos do projeto, a atualização desta planilha ficará em paralelo à identificação de novos riscos e mudanças oriundas de riscos não calculados com exatidão. 87 Figura 20: Fluxograma para Controle de Mudanças de Riscos Fonte: Adaptado de VARGAS, 2013. Esta decisão de não compor o PGP com o PGR foi tomada baseada nos resultados obtidos em tentativas anteriores de publicar este documento, tal informação tornou-se mais importante que o próprio projeto devido à presença inevitável de stakeholders negativos que dependendo de sua influência caracterizada no PGPI, utilizariam seu poder para diminuir o interesse de outros stakeholders afetando diretamente o progresso do projeto. A planilha de riscos é também um documento muito interessante no que diz respeito à todos os fatores que compõem a natureza do risco inerente ao projeto. Pra cada grupo de pacotes de trabalho que fazem parte da WBS do projeto são definidos riscos, também através de sessões de brainstorming 10 , que podem direta ou indiretamente afetar o progresso do projeto. As mesmas divisões da WBS são utilizadas para separar as naturezas dos riscos, elencados em ordem, através de tópicos e que posteriormente serão utilizados para popular a planilha de riscos. Uma outra ferramenta que também pode ser usada para ajudar a elencar os riscos é a RBS - Risk Breakdown Structure 11 , neste organograma, pode-se separar os riscos internos dos externos, assim como subdividir os riscos internos como no nosso exemplo: internos não técnicos (gerenciais ou relacionados a custo, prazo etc), legais (contratos, reclamações etc) e técnicos (operacionais relacionados à tecnologia). Os riscos identificados serão qualificados na sua probabilidade de ocorrência e impacto ou gravidade dos seus resultados, podendo estes serem altos, médios ou baixos. 10 Propõe que um grupo de pessoas se reúna e utilize seus pensamentos e ideias para que possam chegar a um denominador comum, a fim de gerar ideias inovadoras que levem um determinado projeto adiante. 11 É um agrupamento orientado à origem do risco, que organiza, de forma estruturada, classifica e define a exposição dos riscos identificados do projeto ou negócio. 88 Opcionalmente pode-se criar um mapa mental para dar respostas aos riscos que serão planejadas de acordo com a ordem apresentada na figura 21, onde os principais eventos de riscos são os de probabilidade e gravidade altas. Figura 21: Probabilidade x Gravidade de Riscos Fonte VARGAS(2009) Dependendo da natureza dos riscos avaliados pela equipe, pode-se realizar também no PGP uma análise quantitativa dos riscos, mas por se tratar de um projeto onde somente os riscos internos serão avaliados, optou-se por analisar apenas os riscos segundo aspectos qualitativos, utilizando-se o conceito qualitativo de valor agregado, anteriormente apresentado para os riscos identificados. Portanto, não será feita, neste plano, a análise quantitativa dos riscos. Com estes dados em mãos já se pode começar a popular a planilha de riscos, seguindo o padrão proposto por VARGAS(2009), contendo 9 (nove) colunas, cada uma com sua particularidade dependendo do risco em questão, são elas: Número do item na WBS, a fase de entrega, o risco, a probabilidade e a gravidade do acontecimento, o tipo de resposta ao risco (atenuação, transferência ou aceitação por exemplo), descrição detalhada do risco, custo e consequência do tempo de duração do risco. Ao final, assim como os outros planos de gerenciamento do projeto, teremos os tópicos relacionados à reserva de contingência, frequência de avaliação dos riscos, alocação 89 financeira, responsáveis pelo PGR, assim como a frequência de atualização do plano e seu registro de alterações seguidos das aprovações pelo gerente de projeto. 7.1.2.2.8 Plano de Gerenciamento de Aquisições Pela natureza do órgão, secretaria de estado formada por servidores distribuídos em Grupo Ocupacional de Saúde Pública como sendo o conjunto de servidores públicos efetivos que exercem funções de saúde e ou administrativas, nas unidades municipalizadas e ou vinculadas à Secretaria de Estado da Saúde Pública e profissionais de saúde, todos aqueles que estando ou não ocupados no setor saúde, detém formação profissional específica ou qualificação prática ou acadêmica para o desempenho de atividades ligadas direta ou indiretamente ao cuidado ou ações de saúde, este se torna um dos documentos mais importantes de toda a metodologia, é nele que será descrito todo o esquema de contratação e aquisição tanto de pessoal quanto de material ou serviço e consultoria externa. A organização pode ser o comprador ou fornecedor do produto, serviço ou resultado. O PGA do Projeto inclui os processos de gerenciamento de contratos e de controle de mudanças necessários para administrar os contratos ou pedidos de compra. Este gerenciamento inclui, ainda, a administração de qualquer contrato emitido por uma organização externa (o comprador) que está adquirindo o projeto de uma organização executora (o fornecedor) e a administração de obrigações contratuais estabelecidas para a equipe do projeto pelos contratos. O Gerenciamento das aquisições será aqui composto pela Declaração de Trabalho, também chamada de Statement of Work 12 , em suas variantes de Materiais e Treinamentos além dos Cronogramas de cada atividade contratada adicionada ao PGA. Inicialmente foi produzido um documento denominado Declaração de Trabalho – Materiais e Equipamentos, este documento tem como objetivo detalhar as necessidades de aquisição de materiais e equipamentos para o Projeto completo fruto deste trabalho, nele estão contidos a especificação e quantitativo dos materiais e equipamentos a serem adquiridos, para o nosso caso que especificamente trata-se de um projeto de desenvolvimentod e software, compões o documento tanto as necessidades de hardware quanto de software assim como as condições de fornecimento (garantias, suportes, manutenções etc) e a qualificação dos proponentes (fornecedores contratados). 12 Uma descrição dos produtos, serviços ou resultados a serem fornecidos. 90 Complementam o documento, o modelo contratual que define o tipo de contrato a ser firmado com o proponente selecionado assim como o responsável pela autorização de pagamentos de materiais recebidos; além da avaliação de fornecedores que de acordo com o que foi previsto no plano de comunicação do projeto, seriam realizadas reuniões mensais internas do projeto para a avaliação dos resultados do fornecimento de materiais e equipamentos em dias específicos da semana em seguida à reunião mensal de comunicação. O objetivo da reunião seria verificar o cumprimento de prazos, preços e qualidade dos serviços de consultoria. Esta seção define as medidas que podem ser tomadas nos casos de não cumprimento dos itens de contrato por parte dos proponentes selecionados. No caso específico deste projeto de intervenção, todo material de software adquirido foi consequência da parceria existente entre a Universidade Federal do Rio Grande do Norte e a Dreamspark 13 , sistema ligado à Microsoft que disponibiliza softwares para estudantes, pesquisadores e servidores que estão executando projetos de extensão utilizando softwares específicos licenciados para este fim. Com relação ao pessoal, todo o time foi montado por consequência de relotação de pessoal de unidades de referência para o nível central da SESAP. Servidores efetivos do estado que tinham perfil para integrar a equipe de projeto foram requisitados para compor a equipe e juntar esforços no sucesso do projeto, alguns remanejamentos foram necessários para finalizar as contratações, como descrito no relatório de gestão 2013 no ANEXO 1. O documento referente à Declaração de Trabalho – Treinamento foi criado para definir as necessidades da equipe de projeto com relação à conhecimento tanto técnico quanto de gestão. Aqui são elencados tópicos de necessidade geral ou específica para membros da equipe que ocuparão postos importantes na equipe para treinamento, seja de origem técnica ou gerencial. Um detalhe opcional deste documento é o fechamento que pode informar a Qualificação do centro de treinamento contratado ou não de acordo com o perfil de cada órgão, no caso da SESAP, o treinamento necessário foi ofertado por componentes da própria equipe de desenvolvimento que continham perfil de instrutor e aceitaram colaborar através de treinamentos específicos. Ao fim do documento, os registros de alterações devidamente assinados e as aprovações do gerente de projetos complementam o plano. 13 É um Programa da Microsoft que dá suporte a educação técnica fornecendo acesso a software da Microsoft para fins de aprendizado, ensino e pesquisa. 91 7.1.2.2.9 Plano de Gerenciamento de Tempo Logo após a elaboração da EAP dá-se o início a fase de desenvolvimento do Plano de Gerenciamento do Tempo – PGT do Projeto, na proposta inicial este plano era desenvolvido em conjunto com a estimativa de custos, e a gestão de RH e de qualidade, porém eram executadas após o Plano de Contingência que já não era um artefato em si, mas apenas estratégias a serem adotadas como respostas de contingência usadas somente em caso de certos eventos ocorressem, resposta a riscos. Como houve uma alteração no PGR e neste ficou incluído tal plano de contingência, foi necessária uma readequação da metodologia no que diz respeito a pré- requisitos para os planos de gerenciamento de Custo, Tempo, Qualidade e RH. Na proposta inicial estes quatro planos eram executados concomitantemente mas com certa preferência iniciando pelos recursos humanos em seguida estimando cronograma e custos para finalizar com a qualidade. Nesta metodologia final aplicada chegou-se a conclusão de que os quatro planos teriam importância semelhante e seriam alterados simultaneamente no decorrer de seus desenvolvimentos e que o plano de gerenciamento de tempo seria resumido ao cronograma de atividades e marcos, por opção do patrocinador foi solicitado o PGT apenas para constar nos documentos do projeto, porém não seria necessária sua inclusão no PGP final. No PGT deve constar inicialmente uma breve descrição dos processos contidos neste plano como no exemplo aplicado na SESAP, em que o gerenciamento de tempo seria realizado a partir da alocação de percentual completo nas atividades do projeto através da utilização do Microsoft Project 2010. A atualização dos prazos do projeto seria realizada no Microsoft Project através da publicação no site do projeto do gráfico de Gantt, percentual completo de cada atividade e diagrama de marcos. Figura 22: Cronograma do projeto-piloto “Módulo PMO e Base de Dados” Fonte: O próprio autor, 2014 92 É ainda nesta seção que deve ser descrita todas as condições relacionadas a prazo como a folga das atividades expressa em dias, atrasos decorrentes de medidas corretivas, a frequência de atualização da linha de base do projeto e também como será realizada a avaliação de desempenho do projeto, assim como as condições para aceitação nas solicitações de mudanças nos prazos. Em uma segunda seção, deve-se especificar as prioridades relacionadas às mudanças de prazos como mostrado na figura 23, classificando-as em níveis diferentes, no nosso caso 04 (quatro) níveis de prioridade, que trazem todos os métodos utilizados em cada prioridade para recuperação de prazos, se será usado o Fast Tracking 14 , ou o Crashing 15 , horas-extras, banco de horas, mutirões etc. Custos decorrentes destas ações devem ser alocados nas reservas gerenciais. Figura 23: Fluxograma para Controle de Mudanças de Prazos Fonte: Adaptado de VARGAS, 2013. Em seguida algumas informações são desejáveis com relação à margens de atraso ou folgas, no caso da SESAP o projeto não prevê a criação ou a determinação de uma folga ou margem de atraso no término do projeto baseado nos conceitos de corrente crítica, uma vez que a metodologia adotada na construção de cronogramas foi baseada no conceito de caminho crítico, e não no conceito de corrente crítica (Teoria das Restrições) mas para se ter uma ideia da complexidade de uma eventual mudança, será considerado crítica uma mudança com impacto no prazo maior que 5 (cinco) dias. 14 Realizar em paralelo, ou com certo nível de superposição, tarefas que originalmente (devido à concepção ou restrições) seriam feitas em sequência. 15 Procura-se obter a compressão máxima, ou viável, da duração de uma tarefa, verificando-se os impactos nos recursos e custos envolvidos. Nem sempre há viabilidade no processo e frequentemente resultam em aumento de custo. 93 Por opção da equipe com aprovação em reunião pelo corpo de gestores, foi decidido que o documento de PGT não seria extremamente necessário uma vez que todas as informações contidas no documento estariam no plano de gerenciamento do projeto acompanhadas do cronograma elaborado durante o planejamento, segundo GARCIA (2007) proporcionalmente ao excesso de informação, há o excesso de documentos, o que não atende às demandas, gerando lentidão, provocando desinteresse e competição entre produtores de informação, desacreditando o sistema e desestimula o usuário pela dificuldade de encontrar o que procura. Durante o desenvolvimento dos artefatos que iriam compor o plano em curso, a equipe definiu que o diagrama de marcos, atividades concluídas e Gantt formariam um único documento para acompanhamento das atividades no site do projeto pelo corpo gestor e maiores interessados. O diagrama de Gantt foi construído inicialmente baseado na WBS, todos os pacotes de trabalho foram alocados em seus devidos sub-projetos e estes unidos em um único e grande projeto que abarca todos os módulos de desenvolvimento do sistema de gestão hospitalar desejado, o primeiro módulo, utilizado na aplicação desta metodologia, está relacionado à criação do escritório de projetos e o desenvolvimento da base de dados que irá fornecer subsídios aos diferentes módulos do sistema. Em seguida, após a construção do cronograma no diagrama de Gantt, a equipe foi mapeada dentro de recursos, outra planilha que descreve investimentos em horas de trabalho relacionando-as com os investimentos financeiros desprendidos. Todos os recursos após mapeados foram alocados em suas devidas atividades no cronograma para que não houvessem choques de horário de trabalho que resultariam em críticas no diagrama, gerando transtorno na execução do projeto no caso de não ser devidamente corrigido. Um calendário é desejável a este ponto, uma vez que o calendário padrão não é compatível com os horários de trabalho dos servidores públicos da SESAP, com regimes de trabalho variando de 6 a 8 horas diárias, desconsiderando servidores que trabalham em regime de plantão. O calendário é desenvolvido no próprio software Microsoft Project 2010 e incorporado ao cronograma fazendo com que as tarefas sejam automaticamente alocadas nos dias e horários corretos de acordo com a carga horária e disponibilidade da equipe, a partir deste momento o caminho crítico é visualizado. Uma importância ímpar deve ser dada ao caminho crítico do projeto, no caso de cada sub-projeto, uma vez que a metodologia e o plano de gerenciamento de tempo são baseados basicamente no caminho crítico para definição de prioridades e sequências de ações para correções e respostas à riscos. O caminho crítico deve ser apresentado e reunião com o 94 gestor imediato para definição destas ações e alocações de recursos para cobertura de eventuais catástrofes oriundas de atrasos ou desvios de foco dentro do caminho crítico durante a fase de execução, o que influenciará negativa e diretamente o cronograma de todo o projeto. 7.1.2.2.10 Plano de Gerenciamento de Custos O Plano de Gerenciamento de Custos - PGC geralmente é formado pela Decomposição do Orçamento do Projeto por Atividade e por Recurso, Orçamento do Projeto por Recursos, Fluxo de Caixa além da Curva de Desembolso do Projeto, todos anexos ao documento final. O primeiro trata-se do desembolso por pacote de trabalho relacionado na WBS, especificando o gasto para cada pacote de trabalho específico. O segundo traz o investimento realizado para cada recurso da planilha do cronograma separado por seções que distinguem materiais de serviços. O terceiro documento é uma planilha mais detalhada do desembolso por pacote de trabalho incluindo o percentual relacionada a quantidade de unidades disponíveis e a duração de cada atividade por recurso. O fluxo de caixa e a curva de desembolso são relativamente próximos, sendo um expresso em números e o outro graficamente, ambos mostram o crescimento do investimento mês após mês. Com estes quatro documentos em mãos, dá-se início ao desenvolvimento do documento principal de Gerenciamento de Custos que irá integrar o PGP ao final do planejamento, este documento foi necessário visto à importância dada aos investimentos para estabelecimento do escritório de projetos da SESAP assim como para o corpo gestor ter um acompanhamento perfeito no aproveitamento de recursos investidos em servidores. Uma vez que os servidores já existem e não precisam contratar novos participantes ou assessores, houve a necessidade de acompanhar todos os recursos envolvidos no projeto para uma maximização do aproveitamento do servidor junto à SUININ. Antes da criação do escritório de projetos os funcionários existiam porém não tinham demandas e frequentemente eram solicitados para tarefas não relacionadas à seus cargos, desviando o foco de qualquer atividade exercida pela equipe existente assim como atrasando quaisquer entregas pendentes. Com o aproveitamento decorrente da inserção de cada membro na equipe de projetos, o tempo de trabalho de cada servidor foi maximizado e seu acompanhamento é feito em tempo real, assim como descrito por SARRETA (2009) é evidente que quando o 95 trabalhador se sente útil e percebe que sua ação ajuda, há um sentimento de satisfação pessoal e profissional, subjetiva e concreta, o que não existia antes da criação da equipe. Como todo plano de gerenciamento, este documento se inicia com a descrição dos processos de gerenciamento de custos. Assim como o documento de tempo traz todas as atualizações, modificações e extensões de prazos esta seção do documento traz todas as informações relacionadas à caráter financeiro, inflacionário, cambial, considerando mudanças orçamentárias e solicitações de verbas. Em seguida deve existir uma seção exclusiva para as reservas gerenciais aprovadas pelo patrocinador do projeto, as reservas gerenciais se subdividem em Reservas de Contingência 16 e Outras reservas 17 , que, juntamente com o orçamento do projeto, compõem o custo final do empreendimento. No caso do projeto proposto as reservas serão consumidas com base nas solicitações de mudanças provenientes dos outros planos e dentro da autonomia do gerente do projeto e do patrocinador. Na próxima seção traz a autonomia do Gerente de Projetos para utilização das reservas, considerando cada tipo de reserva as três diferentes formas de usá-las, seja isoladamente, com aval do patrocinador ou somente o patrocinador, detalhando quais as faixas de investimentos permitidas para cada caso. No projeto proposto essa autonomia é por cada solicitação de mudanças proveniente dos outros planos, podendo o gerente de projeto consumir a reserva, desde que em diferentes solicitações. Com o fim das reservas, somente o patrocinador poderá solicitar e decidir sobre a criação de novas reservas neste plano. Um trecho opcional do documento faz relação à premiação dos integrantes da equipe ao final do projeto como sendo um percentual das reservas gerenciais restantes em caixa, como o projeto da SESAP contém servidores públicos já remunerados sendo melhor aproveitados em equipes de desenvolvimento, não foi permitida tal situação e portanto retirada do PGC. Em seguida o fechamento do documento traz os responsáveis por alterações no plano assim como sua frequência de atualização e uma pequena planilha de alterações e suas descrições efetuadas no decorrer do projeto. O documento de planilha de custos gerado durante a confecção deste plano é levado à reunião mensal com os gestores para acompanhamento. 16 São reservas destinadas exclusivamente ao processo de gerenciamento de riscos, conforme descrito no plano de gerenciamento de riscos. 17 São todas as reservas destinadas a outros eventos que não são contemplados como riscos do projeto. 96 7.1.2.2.11 Plano de Gerenciamento de Recursos Humanos Com o artefato de planejamento das contratações em mãos, resultado do planejamento das contratações, dá-se início também ao plano de gerenciamento de recursos humanos, esta mudança foi necessária devido à pré-requisitos existentes oriundos das contratações que são frequentemente utilizados no desenvolvimento do documento de PGRH. Durante a construção do PGRH, ficou evidente a necessidade de se constar esse documento no plano final de gerenciamento do projeto, uma vez que os vários artefatos que compõem este documento são de suma importância para o controle e monitoramento dos recursos do projeto, é formado basicamente por uma lista de recursos que traz além da listagem de servidores, a quantidade máxima ofertada para cada especialidade, seus nomes, funções, formas de pagamento e calendário que estão sujeitos, uma taxa padrão de custo é opcional, como no caso da SESAP os servidores já tem seus próprios vencimentos, pode-se fazer uma simples divisão por carga horária e se obter um gasto aproximado por hora de serviço. Adicionalmente à esta tabela, tem-se a planilha de atividades por recurso alocado, “quem faz o quê e quando”, nesta planilha estão listados todos os pacotes de trabalho da WBS relacionados à cada recurso específico assim como as datas de início e término da atividade. Geralmente a entrega do documento é feita contendo um recurso por página, mas pode-se usar uma só planilha para especificar todas as atividades, porém ainda separando por recurso. Com estes artefatos já confeccionados, pode-se dar início a efetiva criação do plano de gerenciamento de recursos humanos, iniciando-se pelo organograma do projeto, o qual estará contido na primeira seção do documento, mostrando todos os recursos divididos em cada especialidade. Logo abaixo do organograma tem-se o diretório do time do projeto, uma simples planilha para listagem de todos os colaboradores incluindo as devidas áreas de atuação no projeto e seus telefones de contato acompanhados do e-mail. Uma boa forma de gerenciar cada participação na criação e posterior evolução dos planos e do projeto em si pode-se inserir na próxima seção do documento uma matriz de responsabilidades, que estende a planilha de diretório do time do projeto trazendo a seguir todas as entregas principais relacionadas na WBS assim como a confecção e administração de cada plano de gerenciamento. A relação do recurso com a responsabilidade é dada através de 3 letras: “R” para o servidor diretamente responsável por aquela atividade específica; “A” 97 para os colaboradores que apoiam algumas execuções e “S” para aqueles que estão na suplência para assumir tal responsabilidade como detalhado na tabela 7 pertencente ao PGRH do projeto. Tabela 7: Matriz de Responsabilidades do Projeto No NOME ÁREA P M O /B as e d e D ad o s C ad as tr o /A d m in is tr aç ão R eg u la çã o E st ad u al R ec ep çã o /A p o io S A D T A m o x/ Fa rm ác ia /E st o q u e R o u p ar ia /H ig ie n iz aç ão Le it o s/ In te rn aç ão /A lt a P .E le tr ô n ic o /A .M éd ic o En fe rm ag em A m b u la to ri al /E m er gê n ci a P ro n to S o co rr o C en tr o C ir ú rg ic o N u tr iç ão /D ie té ti ca P .G .P 1 Rodrigo Xavier Gerência Projeto A S R S A R S A R S A R A S 2 George Borges Programação R R 3 Flavio Silveira Cabral Programação S A R S A R S A R S A R 4 Sergio Alexandre Programação S A S A R S A R S A R S A 5 Augusto Análise de DB A A 6 Denise Guerra Análise de Sistemas S A A A A A A A A A A A A 7 Francisco Carlos Manutenção A 8 Thiago Gondim Manutenção A 9 Douglas Alberto Análise de Suporte A R 10 Fátima Honorato Compras A 11 Flávia Souza Viana Suporte Hospitalar A A A A A A A A A A A A A 12 Altamir Processual A S 13 Dolores Beutemiller Redes e Segurança A A A A A A A S S S S S S S 14 Francisco Canindé Redes e Segurança A S S S S S S A A A A A A A 15 Ricardo Souza Lima Gerência Divisão A A Fonte: O próprio autor, 2014 A quarta seção do documento é crucial, uma das mais importantes de todo o projeto. Aqui que é descrita as diferentes maneiras que novos recursos, re-alocações e substituições de membros do time são realizadas. O gerente de projeto deve se empenhar pessoalmente na permanência de todos os integrantes da equipe durante o projeto e por isso será o coordenador deste plano de recursos humanos. Como no serviço público nada é certo com relação à permanência do recurso na equipe devido à frequentes buscas por melhores condições de vida de vários membros, deve-se desenvolver um plano de substituição isento de falhas para que a equipe não fique desfalcada em nenhum momento. É nesta seção que se deve explicitar a forma com que os recursos serão adicionados ou realocados até mesmo substituídos, deve-se obter junto ao patrocinador autorizações para tais transferências uma vez 98 que a lotação do servidor na SESAP dentro da região metropolitana do RN é baseada na necessidade de cada órgão. Em uma nova seção deve-se expor como será realizada a avaliação de resultados, se o resultado do trabalho da equipe será avaliado mensalmente pelo gerente de projeto em reunião individual com cada membro do time do projeto ou em reuniões conjuntas com os gerentes dos respectivos integrantes do projeto, precisa deixar claro também se o gerente de projeto será avaliado também mensalmente pelo patrocinador do projeto da mesma forma como os membros do time são avaliados. Para o estudo de caso em questão é importante mencionar a avaliação de desempenho anual dos servidores, uma das formas encontradas para avalia-los sem que houvesse injustiça com cada membro era padronizar avaliações de acordo com o cumprimento do cronograma por parte de cada servidor, o acompanhamento através das atividades por recurso alocado ajudaria diretamente o gerente de projetos assim como o gestor da unidade que anualmente emite a avaliação de desempenho de cada membro da subcoordenação. Ainda no documento devem-se expor todas as bonificações relacionadas à equipe, não só financeiras, mas tudo que envolve vantagens devido à permanência do membro na equipe de desenvolvimento do projeto como abono de horas no ponto eletrônico, banco de horas, gratificações e também deve-se expor quais membros estarão sujeitos à estas bonificações, se somente os efetivos ou se chefes de grupo e cargos comissionados também serão beneficiados. O bloco final do documento é padrão, contendo a frequência de avaliação geralmente mensal que é apresentada nas reuniões, assim como a alocação financeira para o gerenciamento de RH, especificando em que reserva será alocada cada utilização. Ao final os responsáveis pelas atualizações e criação deste plano acompanhadas da planilha de alterações e suas devidas descrições e aprovações do gerente de projetos. 7.1.2.2.12 Plano de Gerenciamento da Qualidade O quarto e último plano de gerenciamento desenvolvido em simultaneidade é o de gerenciamento da qualidade. O Plano de Gerenciamento da Qualidade (PGQ) identifica indicadores relevantes ao projeto e determina como satisfazê-los garantindo aderência com as políticas do órgão e conformidade das entregas com seus requisitos. O PGQ descreve como implementar os processos de controle e garantia da qualidade e a melhoria contínua dos 99 processos tendo como base a política da qualidade do órgão e as ferramentas e padrões da qualidade relevantes ao projeto. Durante o planejamento da qualidade geralmente é citado se o projeto estará sendo realizado com base em alguma ISO ou se o órgão possui alguma certificação de qualidade desejada. Durante o projeto em questão todas as reclamações provenientes de usuários, bem como produtos e/ou entregas não conformes com a declaração de escopo deverão ser tratados como medidas corretivas no plano de gerenciamento da qualidade. Ainda na primeira seção do documento deve-se explicar se serão consideradas mudanças nos padrões de qualidade apenas as medidas corretivas ou se inovações e novos níveis de qualidade também serão considerados pelo gerenciamento da qualidade. É importante saber que as medidas corretivas, se influenciadoras no sucesso do projeto, devem ser integradas ao plano. Em uma nova seção mostra-se que as mudanças dos requisitos de qualidade também serão classificadas em quatro níveis de prioridade para este projeto piloto como mostrado na figura 24, que variando de 0 (zero) a 3 (três) classificam-se entre mudanças que devem ou não justificar o contato imediato com o patrocinador no caso de autorizações financeiras urgentes. Quanto menor o grau, mais urgente é a mudança. Figura 24: Fluxograma para Controle de Mudanças da Qualidade Fonte: Adaptado de VARGAS, 2013. A frequência de avaliação dos requisitos de qualidade, a alocação financeira das mudanças nos requisitos de qualidade e a administração do plano de gerenciamento encerram o documento em conjunto com o registro de alterações. Nenhum outro artefato é necessário para este PGQ. 100 7.1.2.2.13 Definindo o Orçamento O orçamento é um cronograma financeiro do projeto, agrega os custos estimados das atividades para estabelecer uma linha de base, no qual se indica como, o quê, e quando serão consumidos os recursos financeiros que afetam o projeto, e de onde virão esses recursos. De fato, tão importante como conhecer os custos e a sua distribuição no tempo, é conhecer quais são as fontes onde iremos buscar os recursos financeiros necessários para fazer face aos custos e em que momentos, ao longo do ciclo de vida do projeto, esses recursos necessitam ser liberados para aplicação. A correta orçamentação do projeto possibilita uma gestão de custos eficiente, a qual, em determinados projetos, pode revelar-se um fator importante para o sucesso do projeto. De acordo com o PMBOK (2013) teríamos 3 saídas durante a determinação do orçamento, toda a documentação do projeto é atualizada e contabilizada como documento de saída, ou seja, a matriz de riscos por exemplo é constantemente atualizada quando desenvolve-se o orçamento. Outra saída importante desta fase são os requisitos de recursos financeiros do projeto, que são gerados a partir da linha de base do desempenho de custos. Considera-se o fluxo de caixa previsto e as necessidades de financiamentos, o que pode implicar em reservas de gerenciamento. O plano de gerenciamento de custos oferece subsídios extremamente importantes para desenvolver o orçamento final. Ao final, a terceira e última saída, a linha de base do desempenho de custos é o orçamento do projeto aprovado pelo seu patrocinador no término do planejamento. Ela pode ser gerada através de uma planilha com as previsões do orçamento ou ainda através do próprio cronograma do projeto como visto anteriormente. No caso do projeto proposto este documento será um relatório quantitativo do plano de gerenciamento de custos, um resumo de tudo que implica gastos será anexado para compor as informações de orçamento do projeto uma vez que os gastos acontecerão apenas para aquisições e no decorrer do projeto com o controle dos custos e mudanças. Ao final das atualizações na metodologia e aplicações do modelo proposto, obteve-se a metodologia final abaixo apresentada para a fase de planejamento: 101 Figura 25: Metodologia Final Proposta – Fase de Planejamento Fonte: O próprio autor, 2014. 7.1.3 Execução 7.1.3.1 Proposta Inicial A fase de execução é a primeira fase que tem um enlace simultâneo efetivo com outras duas fases do projeto, ao mesmo tempo em que ela ocorre existe um contínuo monitoramento e controle e um planejamento constante. A constante organização dos recursos e dos colaboradores que fazem parte do projeto além da busca de colocar em pratica tudo que está no Plano de gerenciamento do projeto é o principal objetivo dessa fase. 102 É durante a execução de um projeto que o planejamento pode ser refeito, basta que ocorra alguma solicitação de mudança e essa seja aprovada, muitas vezes prejudicando a duração e os custos do projeto. Apesar de influenciar durante todas as etapas é durante a fase de execução que os riscos afetam criticamente o projeto, pois ao mesmo tempo que os objetivos vão se concretizando, os possíveis riscos vão se tornando mais prováveis, podendo comprometer o andamento do projeto. A figura 26 ilustra a fase de execução proposta, nela o inicio da fase aconteceria com a aquisição dos recursos, tendo em vista que todos os recursos deveriam estar disponíveis para a execução das atividades planejadas na fase. Figura 26 - Processos da fase de execução inicialmente proposta Fonte: O autor, 2012 Logo em seguida seria iniciado o gerenciamento da equipe do projeto, nesse momento o gerente de projetos mostra toda sua capacidade em administrar; registra a evolução das ações praticadas e agenda o calendário periódico de reuniões esclarecendo eventuais dúvidas sobre a execução do projeto e relatando alguma necessidade, solicitação ou problema. 103 Nessa metodologia assim como no PMBOK o gerenciamento da equipe do projeto ocorreria em simultaneidade com a garantia da qualidade que visa durante a execução do projeto manter um padrão de qualidade aceitável para o objeto em desenvolvimento. Durante essa a fase de execução provavelmente ocorreriam mudanças no projeto e essas mudanças irão afetar outras fases e processos, no caso de uma solicitação de mudança que será registra pelo gerente de projetos a mesma será documentada, e posteriormente analisada, para verificação de possíveis prejuízos na duração das atividades, na disponibilidade dos recursos e o surgimento de riscos. Caso fossem aprovadas estas mudanças, seriam feitos ajustes no plano de gerenciamento de projetos. As modificações seriam então registradas e documentadas e as devidas ações corretivas tomadas e monitoradas. 7.1.3.2 Aplicação e Proposta Final Dando início à fase de execução, o gerente de projetos já se depara com uma situação crítica: todos os recursos sejam humanos ou materiais relacionados em aquisições e contratações precisam estar à inteira disposição do projeto, qualquer exceção leva ao atraso e consequente falha no projeto. É de extrema importância que a equipe tenha em mãos todos os contratos e ordens de serviços confeccionados durante a condução das aquisições, para que os riscos sejam minimizados a partir de documentos base do projeto. A tabela 8 mostra os processos utilizados na fase de execução após correções na metodologia inicial proposta: Tabela 8: Processos contidos na execução da metodologia com suas entradas, saídas e ferramentas PROCESSO ÁREA ENTRADAS FERRAMENTAS SAÍDAS Conduzir Aquisições e Contratações Aquisições Plano de gerenciamento das aquisições Reuniões com licitantes Fornecedores selecionados Documentos de aquisição Técnicas de avaliação de propostas Acordos Critérios para seleção de fontes Estimativas independentes Calendários dos recursos Propostas dos fornecedores Opinião especializada Solicitações de mudança. Documentos do projeto Publicidade Atualizações do Plano de gerenciamento do projeto Decisões de fazer ou comprar Técnicas analíticas Atualizações dos Documentos do projeto Declarações do trabalho das aquisições Negociações das aquisições Ativos de processos organizacionais Desenvolver a Equipe Recursos Humanos Plano de gerenciamento dos recursos Habilidades interpessoais Avaliações do desempenho da equipe 104 Designações do pessoal do projeto Treinamento Atualizações dos Fatores ambientais da empresa Calendários dos recursos Atividades de construção da equipe Regras básicas Agrupamento Reconhecimento e recompensas Ferramentas de avaliação dos funcionários Gerenciar a Equipe Recursos Humanos Plano de gerenciamento dos recursos humanos Observação e conversas Solicitações de mudança Designações do pessoal do projeto Avaliações de desempenho do projeto Atualizações do Plano de gerenciamento do projeto Avaliações do desempenho da equipe Gerenciamento de conflitos Atualizações dos documentos do projeto Registro das questões Habilidades interpessoais Atualizações dos Fatores ambientais da empresa Relatórios de desempenho Atualizações dos Ativos de processos organizacionais Ativos de processos organizacionais Garantir a Qualidade Qualidade Plano de gerenciamento do projeto Ferramentas de gestão e controle da qualidade Solicitações de mudança Métricas da qualidade Auditorias de qualidade Atualizações do Plano de gerenciamento do projeto Medições do controle da qualidade Análise de processos Atualizações dos Documentos do projeto Documentos do projeto Atualizações dos Ativos de processos organizacionais Gerenciar a Execução Integração Plano de gerenciamento do projeto Opinião especializada Entregas Solicitações de mudançaaprovadas Sistema de informações do gerenciamento de projetos Informações sobre o desempenho do trabalho Fatores ambientais da empresa Reuniões Solicitações de mudança Ativos de processos organizacionais Atualizações do Plano de gerenciamento do projeto Atualizações dos Documentos do projeto Gerenciar Comunicação Comunicação Plano de gerenciamento das comunicações Tecnologia das comunicações Atualizações dos Ativos de processos organizacionais Relatórios de desempenho Modelos de comunicações Fatores ambientais da empresa Métodos de comunicação Ativos de processos organizacionais Sistemas de gerenciamento da informação Reportar o desempenho Fonte: Adaptado de PMBOK, 2013 Assim como no modelo proposto o gerenciamento da equipe e a garantia da qualidade acontecem simultaneamente. O gerenciamento da equipe do projeto tem como objetivo acompanhar o desempenho da equipe, fornecer feedback, resolver problemas e 105 coordenar mudanças para melhorar o desempenho do projeto, já a garantia da qualidade tem como objetivo auditar os requisitos da qualidade e os resultados das medidas de controle da qualidade para garantir que os padrões apropriados da qualidade e definições operacionais estão sendo usados. Durante a garantia da qualidade há o gerenciamento constante da execução do projeto assim como a constante consulta de contratos em vigor, que sempre devem estar ao alcance da equipe. Em poucas palavras, certificar-se que tudo que foi planejado está sendo aplicado perfeitamente. O controle de qualidade está muito ligado ao controle de custos, qualquer variação será automaticamente refletida na fase de monitoramento e controle no que se refere aos custos. A partir deste momento toda solicitação de mudança tem que passar por aprovação, como descrito no planejamento no plano de gerenciamento de escopo, qualquer mudança afeta diretamente o orçamento do projeto, por este motivo deve haver um documento para registro tanto da solicitação quanto da autorização pelo patrocinador, todas as mudanças quando aprovadas devem ser monitoradas concomitantemente com a próxima fase de projeto no processo “Controle de Mudanças”, durante o controle de mudanças são registradas todas as solicitações aprovadas que em seguida entram no processo de “Ações Corretivas” da fase de execução para dar prosseguimento efetivo à alteração. É aí que começa o monitoramento e controle do trabalho dando início a fase de monitoramento e controle do projeto. Durante a fase de execução, o projeto proposto à esta secretaria sofreu várias modificações que culminou nesta metodologia final, tais modificações foram aprovadas e documentadas pela equipe do projeto. Os maiores desafios se concentraram durante o processo de “Desenvolvimento e Gestão da Equipe” que por opção da equipe engloba o desenvolvimento a gestão e a mobilização da equipe. O perfil atual de profissionais encontrados na SESAP é muito bom no que se refere a conhecimento técnico, o trabalho em equipe ainda não havia sido explorado e a amplitude existente entre um profissional e outro ainda era desconhecida neste quesito. Durante a distribuição das atividades para constar no relatório de atividades por recurso da fase de planejamento “Quem faz o quê e quando” foi questionado aos programadores da SUININ que métricas de software poderia ser utilizada para distribuição de atividades entre os profissionais, em reunião com o gestor imediato ficou decidido que seria utilizada a técnica de pontos por função para dar complexidade às atividades e 106 consequentemente distribuí-las de acordo com o conhecimento de mundo de cada profissional. As maiores dificuldades apareceram justamente quando membros deixaramd e fazer parte do quadro de pessoal da SESAP e consequentemente desfalcando a equipe. Como previsto no plano de gerenciamento de recursos humanos, imediatamente o patrocinador transferiu e substituiu a força de trabalho daqueles profissionais por outros integrantes da equipe com conhecimentos semelhantes, outro profissional adicional foi integrado para completar a equipe. A capacidade dos servidores anteriores de acumular pontos de função para desenvolver suas atividades era bem distinta da capacidade dos novos servidores, isto influenciou diretamente nos prazos e nos custos do projeto, para minimizar os danos ao projeto foi sugerido ao patrocinador integrar mais um profissional à equipe, o que pode ser confirmado no relatório de gestão de 2013 no ANEXO 1. Para evitar reincidências relacionadas a este caso foi proposto ao gestor imediato mudar a forma de classificar a complexidade das funções e procedimentos dos módulos que seriam desenvolvidos pela equipe, dependendo basicamente do perfil de cada técnico e não considerando um perfil padrão como acontece nos pontos por função. Uma das alternativas seria utilizar uma técnica de metodologia ágil para distribuição das tarefas do escopo chamada Planning Poker 18 . Outra sugestão seria a utilização de uma técnica diferente usada em outra metodologia ágil presente na Extreme Programming chamada Programação em Pares 19 , específica para os casos de desenvolvimento de software, pois haveria sempre um suplente nas atividades de programação específicas dos profissionais programadores diminuindo os riscos de casos semelhantes ao acontecido voltarem a ocorrer. Como previsto na proposta inicial a fase de execução mantém um enlace simultâneo efetivo com outras duas fases do projeto, ao mesmo tempo em que ela ocorre existe um contínuo monitoramento e controle e um planejamento constante. Ao final após mudanças críticas na metodologia, obtém-se o modelo a seguir. 18 Técnica de estimativa baseada no consenso de toda a equipe, onde é utilizado um conjunto de cartas com valores específicos que podem representar pontos relativos ou até mesmo horas (esses valores podem seguir a seqüência de fibonacci) e é praticado como se fosse um jogo. Uma pessoa apresenta a tarefa ou estória para o time, e, após uma breve discussão, cada um escolhe uma carta e coloca virada para baixo sobre uma mesa. Quando todas as cartas estiverem lançadas, elas são viradas e caso não haja consenso nos valores escolhidos, as diferenças são discutidas de forma breve, e uma nova rodada acontece até que haja a convergência. 19 Uma das práticas mais conhecidas e mais polêmicas utilizadas pelos que adotam o Extreme Programming. Ela sugere que todo e qualquer código produzido no projeto seja sempre implementado por duas pessoas juntas, diante do mesmo computador, revezando-se no teclado. 107 Figura 27: Metodologia Final Proposta – Fase de Execução Fonte: O próprio autor, 2014. 7.1.4 Monitoramento e Controle 7.1.4.1 Proposta Inicial A fase de monitoramento e controle (Figura 28) assim como citado no guia PMBOK serve para observar o andamento do projeto e a garantia dos seus indicadores, ela possui uma constante ligação e interação com a fase anterior (execução), e uma interação secundária com a fase de planejamento, fato que se consolida no momento em que as alterações no projeto são solicitadas, analisadas e aprovadas. É durante essa fase que os trabalhos concluídos são monitorados, além do acompanhamento do desempenho do projeto, sendo feita a observação e medição regularmente identificando possíveis variações em relação ao plano de gerenciamento do projeto. A metodologia proposta não foi feita com o propósito de controlar tudo de forma arbitrária, mas com o intuito de diminuir problemas e tornar mais ágil o andamento do projeto, o foco principal desse monitoramento seria a identificação de atividades que pertencem ao caminho crítico, as que são “gargalos”, as que são responsáveis por grandes desembolsos e as que são conclusivas. 108 No caso do monitoramento e controle das mudanças ocorridas as devidas ações corretivas seriam tomadas e monitoradas como os demais processos do projeto. Figura 28 - Processos da fase de monitoramento e controle inicialmente proposta Fonte: O autor, 2012 7.1.4.2 Aplicação e Proposta Final A proposta inicial de monitoramento e controle deixou a desejar no quesito “acompanhamento”, com a frequente atualização de status tanto de desenvolvimento da execução quanto de trabalho realizado havia a necessidade de feedback para os gestores e patrocinador do projeto. Como não havia sido previsto nenhum relatório ou planilha de acompanhamento o interesse foi caindo diretamente proporcional ao tempo decorrido de trabalho, remetendo diretamente à planilha de stakeholders fazendo com que partes interessadas negativas e influentes viessem à tona novamente para influenciar as outras partes interessadas a não mais dar apoio ao projeto. Com isso depois de algumas reuniões foram criados os relatórios de Termo de recebimento de entregas, planilha de controle das mudanças, controle das entregas, relatório de desempenho assim como o relatório de acompanhamento do projeto, na maioria das vezes utilizando-se de outros artefatos já citados como a WBS para manter os gestores informados semanalmente fazendo com que o interesse se mantivesse estável. 109 A tabela 9 descreve os processos utilizados na fase de monitoramento e controle pela metodologia final após correções e detalha entradas, saídas e ferramentas utilizadas segundo Guia PMBOK: Tabela 9: Processos contidos no monitoramento da metodologia com suas entradas, saídas e ferramentas PROCESSO ÁREA ENTRADAS FERRAMENTAS SAÍDAS Controlar Comunicação Comunicação Plano de gerenciamento do projeto Sistemas de gerenciamento da informação Informações sobre o desempenho do trabalho Comunicações do projeto Opinião Especializada Solicitações de mudança Registro das questões Reuniões Atualizações do Plano de gerenciamento do projeto Dados sobre o desempenho do trabalho Atualizações dos Documentos do projeto Ativos de processos organizacionais Atualizações dos Ativos de processos organizacionais Controlar e Monitorar o Trabalho Integração Plano de gerenciamento do projeto Opinião especializada Solicitações de mudança Previsões do cronograma Técnicas analíticas Relatórios de desempenho do trabalho Previsões de custo Sistema de informações do gerenciamento de projetos Atualizações do Plano de gerenciamento do projeto Mudanças validadas Reuniões Atualizações dos Documentos do projeto Informações sobre o desempenho do trabalho Fatores ambientais da empresa Ativos de processos organizacionais Controlar Custos Custos Plano de gerenciamento do projeto Gerenciamento do valor agregado Informações sobre o desempenho do trabalho Requisitos de recursos financeiros do projeto Previsão Previsões do orçamento Dados sobre o desempenho do trabalho Índice de desempenho para término Solicitações de mudança Ativos de processos organizacionais Análise de desempenho Atualizações do Plano de gerenciamento do projeto Software de gerenciamento de projetos Atualizações dos Documentos do projeto Análise de reservas Atualizações dos Ativos de processos organizacionais Controlar Cronograma Tempo Plano de gerenciamento do projeto Análise de desempenho Informações sobre o desempenho do trabalho Cronograma do projeto Software de gerenciamento de projetos Previsões do cronograma Dados sobre o desempenho do trabalho Técnicas de otimização de recursos Solicitações de mudança Calendários do projeto Técnicas de criação de modelos Atualizações do Plano de gerenciamento do projeto Dados do cronograma Antecipações e esperas Atualizações dos Documentos do projeto Ativos de processos organizacionais Compressão de cronograma Atualizações dos ativos de processos organizacionais Ferramenta de cronograma 110 Controlar Escopo Escopo Plano de gerenciamento do projeto Análise de variação Informações sobre o desempenho do trabalho Documentação dos requisitos Solicitações de mudança Matriz de rastreabilidade dos requisitos Atualizações do Plano de gerenciamento do projeto Dados sobre o desempenho do trabalho Atualizações dos documentos do projeto Ativos de processos organizacionais Atualizações dos ativos de processos organizacionais Fonte: Adaptado de PMBOK, 2013 De início, após as ações corretivas da fase de execução é iniciado o monitoramento e controle do trabalho, segundo o Guia PMBOK (2013), monitorar e controlar o trabalho do projeto é o processo de acompanhamento, revisão e ajuste do progresso para atender aos objetivos de desempenho definidos no plano de gerenciamento. Ele é composto de:  Coleta, medição e disseminação de informações sobre desempenho;  Avaliação de medições e tendências para efetuar melhorias no processo. É muito importante monitorar e controlar o trabalho do projeto, principalmente, para avaliar a saúde do seu projeto durante todo o projeto assim como identificar áreas que exigem atenção especial para recomendar ações para corrigir ou evitar os desvios assim garantindo a qualidade (saúde) do projeto através do monitoramento, check-list e contingência prevista anteriormente. O monitoramento e controle do trabalho afeta diretamente o controle do cronograma, através dele ainda podem ser feitos ajustes tanto no PGP quanto nos documentos do projeto e consequentemente podem influenciar no cronograma, por este motivo a metodologia propõe que remeta ao planejamento um processo para controle desse cronograma. Não menos importante em seguida aparece o monitoramento dos custos do projeto, sempre que envolva alteração do cronograma consequentemente afetará os custos finais do projeto, isto deverá constar no relatório de desempenho que será apresentado em reunião semanal para controle de alterações no orçamento. Em contrapartida temos a verificação de trabalhos concluídos que, dependendo da agilidade da entrega do pacote de trabalho, este também remeterá ao controle de custos fazendo com que haja acréscimo ou diminuição no orçamento, toda alteração entra novamente no relatório de desempenho para confrontar informações e saber o real impacto sobre os custos do projeto. Ao formalizar o 111 aceite das entregas, um relatório chamado “controle das entregas” é atualizado e o escopo é controlado e validado através da atualização do relatório de desempenho. Este relatório é de suma importância para o sucesso da fase de monitoramento e controle. Com os novos relatórios inseridos na metodologia, o monitoramento do projeto de desenvolvimento do sistema gestor hospitalar da SESAP pôde caminhar com mais tranquilidade sem muita intervenção de partes interessadas negativas. O relatório de desempenho foi crucial para manter o interesse do patrocinador no projeto engajando cada vez mais a equipe no interfaceamento com a fase de execução. Em seguida, após o processo de formalização do aceite das entregas dá-se início a fase de encerramento de cada projeto ou sub-projeto. Os controles de qualidade, aquisições e comunicações disponíveis no PMBOK (2013) não foram contemplados na metodologia final devido à agilidade e prioridade que se queria dar ao processo de execução, uma vez que no serviço público, aquisições e comunicações são praticamente constantes devido à forma de condução foi decidido pela equipe que não seria necessário investir tanto esforço pra controlar algo que provavelmente não seria alterado. Ao final das modificações no modelo, a metodologia foi finalmente atualizada e fica retratada na imagem a seguir. Figura 29: Metodologia Final Proposta – Fase de Monitoramento e Controle Fonte: O próprio autor, 2014. 112 7.1.5 Encerramento 7.1.5.1 Proposta Inicial A fase de encerramento inicialmente proposta faria uma interação com o monitoramento e controle ao mesmo tempo em que fosse verificada a conclusão dos trabalhos e esses fossem aceitos pelos stakeholders, essa aceitação seria devidamente documentada gerando com isso um documento chamado atestado de capacitação técnica, que serviria como um manual do produto obtido com a conclusão do projeto. As demais documentações expedidas a respeito do projeto seriam arquivadas e utilizadas como base para outros projetos ou para consultas posteriores, após isso seria feita uma reunião para se identificar as lições aprendidas no decorrer da elaboração do projeto. Essas lições visam avaliar todos os parâmetros do projeto, elas registram as causas das variações, razões sob os planos de ação para eliminação de situações insatisfatórias, análise dos erros cometidos no gerenciamento dos parâmetros listados anteriormente e acertos realizados durante o projeto, após isso elas são devidamente documentadas e consolidadas, visando a aplicação das mesmas em projetos futuros. A figura 30 ilustra a fase de encerramento e seus processos: Figura 30 - Processos da fase de encerramento inicialmente proposta Fonte: O autor, 2012 113 7.1.5.2 Aplicação e Proposta Final Não houve alterações substanciais no que se diz respeito às metodologias propostas e a final no conjunto da obra, apenas alguns artefatos foram criados para dar um fechamento formal às atividades assim como feedback aos gestores e patrocinador. A tabela 10 detalha todos os processos utilizados na fase de encerramento da metodologia final proposta com suas entradas, saídas e ferramentas utilizadas. Tabela 10: Processos contidos no encerramento da metodologia com suas entradas, saídas e ferramentas PROCESSO ÁREA ENTRADAS FERRAMENTAS SAÍDAS Encerrar Aquisições e Contratações Aquisições Plano de gerenciamento do projeto Auditorias de aquisições Aquisições encerradas Documentos de aquisição Acordos negociados Atualizações dos ativos de processos organizacionais Sistema de gerenciamento de registros Encerrar Projeto Integração Plano de gerenciamento do projeto Opinião especializada Transição do produto, serviço ou resultado final Entregas aceitas Técnicas analíticas Atualizações dos ativos de processos organizacionais Ativos de processos organizacionais Reuniões Fonte: Adaptado de PMBOK, 2013 A cada aceite de entrega foi decidido pela equipe que um analista de sistemas assumiria a responsabilidade de criar o atestado de capacitação técnica, na verdade um manual descrevendo todas as funcionalidades e operacionalizações do módulo ou pacote desenvolvido, para que no final não haja perda de foco utilizando a pouca força de trabalho existente engajada no projeto para desenvolver manuais de utilização. A cada entrega os contratos são revistos e para cada caso, finalmente encerrados gerando um termo de encerramento de contrato para constar nos documentos do projeto. As lições aprendidas com cada entrega são documentadas gerando uma base de conhecimento que posteriormente fará parte dos ativos processuais do órgão, documento utilizado na fase de iniciação do projeto para descrever com exatidão o perfil do órgão sem precisar de pesquisas documentais aproximadas e sessões de brainstorm, ou seja, um banco de dados de informações que serão utilizadas para traçar um perfil da SESAP contendo informações sobre como cada setor funciona, o que funciona direito e de que forma. Após todas as entregas do projeto serem efetuadas finalmente o projeto ou sub- projeto é encerrado gerando o termo de encerramento de projeto, este termo será gerado para cada sub-projeto e para o projeto final. Uma reunião final é solicitada para avaliações e 114 compartilhamento de lições aprendidas. Ao final das experiências na fase de encerramento, a metodologia tomou a forma da figura a seguir. Figura 31: Metodologia Final Proposta – Fase de Encerramento Fonte: O próprio Autor, 2014. 115 8. AVALIAÇÃO DOS RESULTADOS A participação do escritório de projetos na SESAP pode ser relacionada ao que vemos em CINTRA (2007) quando sugeriu que para a implementação do gerenciamento de projetos, houvesse inicialmente, uma maior compreensão dos conceitos para uma efetiva institucionalização do Escritório de Projetos, uma “ferramenta” essencial para a implantação de uma metodologia tão customizada para um órgão de tamanha importância. CINTRA (2007) ainda afirmou ao final de seu estudo que também havia a necessidade de seleção de colaboradores que tivessem habilidades para utilizar, elaborar e acompanhar o desenvolvimento dos projetos dentro de cada secretaria, fundação e/ou autarquia, apontando para a criação de uma comunicação efetiva com o escritório e visando atendimento das funções necessárias. Ou seja, de nada adianta um escritóriode projetos numa organização se o corpo funcional não tem conhecimento suficiente para lidar com trabalho em equipe focado em tarefas com início, meio e fim bem definidos. A existência da elaboração de projetos na SUININ devolve à subcoordenadoria a esperança de voltar a ser valorizada e ter seu orçamento normalizado com relação aos repasses da coordenadoria que historicamente não existe devido à esta inexistência de projetos por parte da SUININ já citada no decorrer deste trabalho. Muitas tentativas já foram feitas com relação ao incremento da equipe e por vezes negada, os profissionais de TI geralmente estavam lotados em atividades que sequer eram inerentes ao cargo, em hospitais ou em cargos administrativos como citado pelo TCE(2013) em seu relatório de auditoria. Ao ser apresentado o projeto e a equipe se deparar com o risco mais perigoso e imprevisível com a perda de um servidor por concurso público, rapidamente foi refeita com a convocação de não apenas um, mas três outros servidores profissionais de TI como citado no relatório de gestão (ANEXO 1). A SESAP atualmente tenta manter a equipe de projetos bem informada e capacitada através não só de atualização e capacitação interna como também de contínuas aplicações da metodologia proposta, mesmo isto representando alguns dos riscos citados no PGR. A possibilidade de fragmentar a equipe para criar uma outra divisão para gerenciar um projeto paralelo com maior apelação social e política é inevitável uma vez que estes interesses nunca deixarão de existir tanto no serviço público quanto privado. Afortunadamente apenas um projeto foi criado para implantação paralela a este projeto de intervenção, como a resposta aos riscos de nossa metodologia sugeriu um profissional a mais em cada área de atuação para 116 que não houvesse muito dano ao cronograma do projeto corrente, pôde-se criar uma segunda equipe de projetos para desenvolver a Rede de Talentos solicitada pelo secretário Estadual de Saúde Luiz Roberto Fonseca, mostrando mais uma vez o comprometimento e responsabilidade com a gestão democrática e participativa, solicitou um sistema de informação para apoiar na seleção de diretores, gestores e principalmente cargos em comissão assim como em cargos que requerem maior conhecimento técnico, valorizando assim o servidor com relação à meritocracia. O TCE/RN já alertava acerca do conhecimento dos gestores encontrados na SESAP em seu último relatório de auditoria quando sugeriu ao final do documento “definir critérios técnicos mínimos para a ocupação de cargos de gestão, principalmente, os de direção nos hospitais.” A metodologia proposta neste trabalho de intervenção foi aplicada também durante o desenvolvimento da aplicação desta Rede de Talentos, por ser um projeto reduzido devido à utilização de recursos oriundos do portal do software público brasileiro, a existência de um profissional de cada área foi suficiente para que em 2 (dois) meses fossem concluídos os trabalhos, apresentando no dia 11 de março de 2014 o lançamento da Rede de Talentos da SESAP. O sucesso no desenvolvimento da aplicação resultou na primeira premiação recebida pela SUININ, através de uma medalha de honra ao mérito, o prêmio foi recebido pelo patrocinador e subcoordenador da SUININ, Ricardo Lima e representaram a equipe de projetos o gerente de projetos Rodrigo Xavier, o desenvolvedor Flávio Cabral e o analista de sistemas Augusto. Para o secretário de saúde, Luiz Roberto Fonseca, “a Rede de Talentos era um anseio antigo de todos os servidores. É um instrumento que vai fortalecer a meritocracia, pois poderemos facilmente identificar competências, e assim alocarmos de forma responsável o que temos de melhor. É a valorização da prata da casa, algo inédito na gestão pública estadual”. Toda esta situação corrobora com o sucesso da metodologia no âmbito da SESAP, através do perfil atual da organização aliado aos ativos processuais organizacionais pode-se manter a metodologia sempre atualizada de acordo com o perfil monitorado. As dificuldades encontradas durante a aplicação da proposta inicial eram esperadas visto à inexperiência de grande parte da equipe e também do desconhecimento parcial de parte da equipe com relação ao gerenciamento de projetos, treinamentos internos sem envolver investimentos e recursos externos foram essenciais para o sucesso do projeto, seguidas alterações na metodologia eram feitas para mitigar riscos ao mesmo tempo em que eram identificados. 117 Espera-se após a conclusão total deste projeto proposto uma economia na ordem de R$ 1.284.000,00 (Um milhão e duzentos e oitenta e quatro mil reais) anuais referentes à doze parcelas de R$ 107.000,00 (Cento e sete mil reais), custos relacionados a softwares proprietários referidos anteriormente neste trabalho, custos que serão realocados em áreas ainda mais deficientes que demandam urgência e investimentos. De acordo com o Portal da Transparência do Estado do Rio Grande do Norte, a Secretaria Estadual de Saúde conta com um orçamento de aproximadamente R$ 23.000.000,00 (Vinte e três milhões de reais) o que significa uma economia de aproximadamente 5%, uma marca desejável pelo projeto proposto. 8.1 CONSIDERAÇÕES FINAIS Alcançar a excelência de gerenciamento de projetos ou mesmo a maturidade pode não ser possível sem o uso de processos repetitivos que podem ser usados no projeto. Estes processos repetitivos são referidos como a metodologia de gerenciamento de projetos, onde o contínuo uso desta metodologia aumentará drasticamente as chances de sucesso de uma organização. (KERZNER, 2001 apud FERREIRA, 2001, p. 12). O grande desafio de gerenciar projetos com eficiência e a busca pelas melhores práticas são fatores críticos para o sucesso, essa ação requer esforço em adotar uma metodologia única, diante disso o gerente de projetos é a figura que possui os requisitos para analisar as necessidades de cada projeto. A realização deste trabalho esclareceu alguns pontos a respeito de uma atividade inerente ao gerente de projetos que é o desenvolvimento de uma metodologia de gerencia de projetos, além de proporcionar a sua extensão a outros trabalhos futuros. Tendo como principal objetivo propor uma metodologia de gerenciamento de projetos baseado no modelo PMBOK (2013), e cientes que os processos de gerenciamento de projetos são bastante semelhantes nas diversas áreas e organização concluímos que a proposta de metodologia, que visa propor padrões de sequenciamento de atividades e produção de artefatos e produtos, permitirá a SESAP uma maior agilidade nos seus projetos. Em virtude da complexidade do PMBOK, as boas práticas foram garantidas, contudo a busca pela melhora na agilidade foi o foco, e a expectativa que esse objetivo se concretize com perfeição é necessário o aprimoramento da metodologia com outros processos de desenvolvimento ágil como scrum e extreme programming para tornar a metodologia não só imune à burocracia e individualidades dos processos políticos como também ágeis e eficientes no estabelecimento de metas e diretrizes que requerem urgência em um cronograma mais eficaz. 118 Como citado por CINTRA(2007) o processo de modernização da gestão dos órgãos públicos tem sido incentivado, porém, o que se verifica na prática são iniciativas incipientes. Assim, uma análise no processo de gestão efetiva de projetos em entidades públicas poderá subsidiar outros órgãos públicos em seus processos de implantação de metodologias de gestão em relação a possibilidades de novos caminhos, a partir dos acertos e erros, os quais possibilitam eliminar algumas etapas iniciais desse processo cognitivo. Assim sendo, este trabalho contribui para a prática da gestão pública, no sentido de subsidiar outras experiências similares quanto aos aspectos que devem ser observados no processo de implementação de novas práticas gerenciais. Espera-se que a aplicação sistemática e universalizada desta metodologia contribua fortemente para implantar uma cultura de planejamento e gerenciamento de programas e projetos, favorecendo a incorporação dos fundamentos e princípios do modelo de gestão pública para a excelência. 119 REFERÊNCIAS ABIDI, S.S.R. Healthcare knowledge management through building and perationalizing healthcare enterprise memory. In: Medical Informatics in Europe. Amsterdam: IOS Press, 1999. ABNT – Associação Brasileira de Normas Técnicas. NBR ISO 10006 - Gestão da qualidade - Diretrizes para a qualidade no gerenciamento de Projetos processo, Rio de Janeiro, RJ: ABNT, 2003. ______,______ NBR 14724: informação e documentação – Trabalhos acadêmicos – Apresentação. Rio de Janeiro, Abr 2011. ANYOSA, Victor. Simplificando la complejidad de los proyectos: Más allá de comerse al elefante en pedacitos. PMI Global Congress Latin America, São Paulo, 2008. ASH, J. Factors affecting the diffusion of the computer-based pacient record. Biomedical Information Communication Center – Oregon Health Sciences University. Applications for computer simulation in medical scheduling. Annals of emergency medicine, Portland, v. 22, n. 2, p.134-140, mai. 1989. Biblioteca Virtual em Saúde. DATASUS – Trajetória 1991-2002. [homepage na internet] Brasília, DF: Ministério da Saúde; 2002; [acesso em: 19/Mar/2014] Disponível em: http://bvsms.saude.gov.br/bvs/publicacoes/trajetoria_datasus.pdf BROWN, R. Rational Choice and Judgment Decisor Analysis for the Decider. Hoboken: Wiley, 2005. CANOTILHO, José Joaquim Gomes (org.); LEITE, José Rubens Morato (org.). Direito Constitucional Ambiental Brasileiro. São Paulo: Saraiva, 2007. CINTRA, Renato Fabiano. A Ferramenta de Gestão de Projetos: um Estudo de Caso na Prefeitura Municipal de Dourados-MS. UFGD, 2007. CLELAND, D. I. & IRELAND, L. R. Project Manager’s Portable Handbook. New York: McGraw-Hill, 2000. CLEMEN, R. T. e REILLY, T. Making Hard Decisions With Decisions Tools. Pacific Grove: Duxbury, 2001. D’ÁVILA, Márcio. PMBOK Guide e Gerenciamento de Projetos. Disponível em: http://www.mhavila.com.br/topicos/gestao/pmbok.html Acesso em 12/06/2013. DINSMORE, Paul C.; CABANIS-BREWIN, Jeannett. AMA: Manual de Gerenciamento de Projetos. Rio de Janeiro, RJ: Brasport, 2009. __________, Paul C. Transformando Estratégias Empresariais Através de Gerência de Projetos. Qualitymark Ed., 1999. 120 __________, Paul C. Winning in business with enterprise project management. New York: Amacon, 1998. Ferraz, Lygia Helena Valle da Costa. O SUS, o DATASUS e a informação em saúde: uma proposta de gestão participativa. Rio de Janeiro: s.n., 2009. GARCIA, Joana Coeli Ribeiro. Biblioteca universal: um sonho antigo da humanidade. Encontros Bibli, núm. 23, primer semestre, 2007, pp. 62-72. Universidade Federal de Santa Catarina, Brasil. GUEDES e SAMBO. Gestão e Tecnologia Hospitalar. TI e saúde: diagnóstico de crescimento, n 3, p. 12, Set/Out 2010. GIL, Antônio C. Métodos e técnicas em pesquisa social. São Paulo: Atlas, 1999. HELDMAN, Kim. Gerencia de projetos - fundamentos: um guia prático para quem quer certificação, 5ª. Edição. Rio de Janeiro, RJ: Elsevier, 2005. HENDERSON, J. C. e VENKATRAMAN, N. Strategic Alignment: Leveraging Information Technology for Transforming Organizations. IBM Systems Journal, v. 38, n. 2-3, p. 472-484, 1999. JARDIM, JM. A Face oculta do leviatã. Rev. Serv. Pub. Jan/2008; 59(1), p. 81-92. KAPLAN, B. Evaluating informatics applications – some alternative approaches: theory, social interactionism and call for methodological pluralism. International Journal of Medical Informatics, New Haven, v. 64, p. 39-56, nov. 2001. KERZNER, Harold. Gestão de projetos: as melhores práticas, 2ª Edição. São Paulo, SP: Bookman, 2008. ____________, Harold. Project Management – A Systems Approach to Planning, Scheduling, and Controlling, New York NY, John Willey & Sons, 2001. Apud FERREIRA, Gleison Emilio. Proposta de plano de gerenciamento de projetos: estudo de caso para a mudança de local de um escritório de consultoria. Niteroi: EDUFF, 2001. KROLL , K. M. Small projects, big results. PM network. vol. 21, n. 7, Jul 2007, p. 28-33. LARSON, Richard and Elisabeth. The critical steps to managing small projects. PMI Global Congress Proceedings. Prague, 2004. LAURINDO, F.J.B.; SHIMIZU T.; CARVALHO, M.M.; RABECHINI R. O papel da tecnologia da informação (TI) na estratégia das organizações. Revista do Departamento de Engenharia da Produção da. Universidade Federal de São Carlos. São Paulo, v. 8, n.2.p.160-179, ago. 2001. LAURINDO, F. J. B. e ROTONDARO, R. G. Gestão Integrada de Processos e da Tecnologia da Informação. São Paulo: Atlas, 2008. 121 Lima NT, Fonseca CMO, Hochman Gilberto. A Saúde na Construção do Estado Nacional no Brasil: Reforma Sanitária em Perspectiva Histórica. In: Lima NT, Gerschman S, Edler FC, Suárez JM. Saúde e democracia – história e perspectivas do SUS. Rio de Janeiro: Editora Fiocruz;2006. MANSUR, R. Implementando um Escritório de projetos. Rio de Janeiro: Brasport, 2007 Michaelis Moderno Dicionário da Língua Portuguesa. Disponível em: http://michaelis.uol.com.br/moderno/portugues/index.php. Acesso em 12/06/2013. Michaelis Moderno Dicionário Inglês. Disponível em: http://michaelis.uol.com.br/moderno/ingles/index.php. Acesso em 12/06/2013. Ministério da Saude-DATASUS. Política Nacional de Informação e Informática em Saúde – Proposta v. 2.0.[homepage na internet] Brasília, DF:Ministerio da Saude; [acesso em: 19/Mar/2014] Disponível em: http://www2.datasus.gov.br/DATASUS/APRESENTACAO/PoliticaInformacaoSaude29_03_ 2004.pdf PAROLIN, Sonia Regina Hierro. Elaboração de projetos inovadores na educação profissional. 2ª Edição. Curitiba, PR: Senai, 2008. PARTH, Frank R.. Categorization of small projects. 29th Annual PMI Seminars & Symposium. Long Beach, 1998. PASSOS, Maria Luiza G. S. Gerenciamento de Projetos para Pequenas Empresas. Rio de Janeiro: Brasport, 2008, 294 p. PMI – Project Management Institute, Um guia do conhecimento em gerenciamento de projetos – Guia PMBOK, 4ª Edição. ISBN: 9781933890708., PMI, 2008. PORTER, M. E. Strategy and the Internet. Harvard Business Review, v. 79, n. 3, p. 63-78, 2001. Tribunal de Contas do Estado do Rio Grande do Norte. Relatório Preliminar de Auditoria Operacional na Rede Hospitalar da Secretaria de Estado da Saúde Pública do Rio Grande do Norte, 2013. RINCON, Ivan. Mini and Micro Projects: Are PM principles applicable to small companies or small projects? PMI Global Congress Proceedings. Madrid, 2006. RODRIGUES FILHO, José; XAVIER, Jefferson Colombo B. and ADRIANO, Ana Lívia. A tecnologia da informação na área hospitalar: um caso de implementação de um sistema de registro de pacientes. Rev. adm. contemp. [online]. 2001, vol.5, n.1, pp. 105-120. ISSN 1982-7849. ROESCH, M. A. Sylvia. Projeto de Estágio do Curso de Administração: guia para pesquisas, projetos, estágios e trabalho de conclusão de cursos. 1ªº ed. São Paulo: Atlas, 1996. 122 SARRETA, FO. Educação permanente em saúde para os trabalhadores do SUS [online]. São Paulo: Editora UNESP; São Paulo: Cultura Acadêmica, 2009. 248 p. SISK, T.; History of Project Management. 1998. SILVA, Raimundo Paulino da. Políticas Públicas de Saúde. 2009. STANDISH GROUP. CHAOS: pesquisa sobre o desenvolvimento de software e o panorama da indústria de Tecnologia da Informação na atualidade. THORN, Jeff and DIXON, Colleen. Choosing Just the Right Level of Project Management for Small Projects, Unpublished paper for George Washington University Executive Decision Making Class, Dr. Ernest Forman. Fall, 2004. TRIVIÑOS, A. N. S. Introdução à Pesquisa em Ciências Sociais. São Paulo: Atlas, 2007. VARGAS, Ricardo Viana. Qual é o significado real da palavra projeto? Disponível em: http://www.ricardo-vargas.com/pt/podcasts/projetodef/ Acesso em 12/06/2013. ______,______. Manual prático do plano do projeto. 4ª. Edição. Rio de Janeiro, RJ: Brasport, 2009. Disponível em: http://issuu.com/ricardo.vargas/docs/man4ed Acesso em 12/06/2013 ______,______. Gerenciamento de Projetos: Estabelecendo Diferenciais Competitivos. 7a edição – 2009, 276 páginas. Rio de Janeiro, RJ: Brasport, 2009. VERZUH, E. The Fast Forward MBA in Project Management. 2. Ed. New York: John Wiley, 2005. VIEIRA, Eduardo Newton Oliveira. Gerenciando projetos na era de grandes mudanças – uma breve abordagem do panorama atual. PMI Journal – PMI-RS 3, 2002. pp. 7-16. YASBEK, J; A; C. PMO (Project Management Office): estudo de aplicação para empresas construtoras de obras de infra-estrutura. São Paulo: USP, 2005. Dissertação (Mestrado em Engenharia), Escola Politécnica, Universidade de São Paulo, 2005. 123 APENDICES 124 APENDICE A – FASES DA METODOLOGIA INICIAL PROPOSTA 125 APENDICE B – FASES DA METODOLOGIA FINAL PROPOSTA 126 APENDICE C – APRESENTAÇÃO DO PROJETO Apresentação do Projeto Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH APRESENTAÇÃO DO PROJETO Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Ricardo Souza Lima – Patrocinador – Subcoordenador 02/09/2013 A convite do DATASUS/RJ, com sede na Rua México, 128 – Centro, Rio de Janeiro, compareceram à reunião o subcoordenador de informação e informática Sr. Ricardo de Souza Lima e parte da divisão de desenvolvimento de sistemas da Secretaria de Estado da Saúde Pública do RN representados por Rodrigo Xavier, programador de sistemas e Denise Guerra, analista de sistemas, para discutir alternativas ou a possibilidade de adesão ao sistema e-SUS hospitalar à ser instalado nas várias unidades de saúde do Brasil após sua transferência de tecnologia que ocorreria em outubro de 2013. Após seguidas reuniões contando com a presença do então Gestor do HOSPUB Sr. Paulo Renato e do representante do DATASUS no estado de Rondônia ficou claro o investimento exorbitante que seria necessário para configuração, instalação, implantação e treinamento além de licenças de uso de sistemas terceiros que seriam necessários para a utilização do e-SUS hospitalar e outras licenças para uso irrestrito do banco de dados proprietário utilizado pela então desenvolvedora do software TOTVS sem possibilidade ágil de mudança. Para constar, o software e-SUS hospitalar ainda estava, nesta data, em testes no Hospital Federal do Rio de Janeiro, o qual foi alvo de visitas técnicas realizadas por esta mesma equipe para conhecimento e maior contato com o sistema. Após uma última reunião contando com a presença de representantes do Ministério da Saúde e também de representantes da empresa responsável pelo software TOTVS discutiu-se a possibilidade de alterar o banco de dados proprietário utilizado atualmente por um bano de dados livre após a transferência de tecnologia, porém os gastos exorbitantes com implantação, treinamento e licenças de uso dos módulos ERP da TOTVS obrigatórios para uso do sistema e-SUS tornaram a implantação um tanto questionável com relação aos gastos atuais praticados pela SESAP junto à empresa e software SALUX instalado atualmente na rede hospitalar. Uma auditoria havia sido realizada naquele mesmo ano pelo Tribunal de Contas do Estado que através do processo 000661/2012 do TCE PLENO acolheu o relatório final de auditoria de folhas nº 1.543/1.739 e recomendou à Secretaria Estadual de Saúde Pública do Rio Grande do Norte - SESAP a execução de 82 providências a serem distribuídas em várias áreas de atuação dentro da secretaria, dentre as recomendações foram encontradas: 34) planejar, juntamente com os hospitais, de acordo com as necessidades levantadas e o planejamento orçamentário, a aquisição de sistemas HIS(Sistema de Informação Hospitalar), RIS (Sistema de Radiologia Digital) e PACS (Sistema de Comunicação e Arquivamento de Imagens) para incorporação ao parque tecnológico dos hospitais (item 269 do relatório final de auditoria); 42) implantar software de gestão hospitalar (SALUX ou alguma das soluções disponíveis no Ministério da Saúde), com funcionalidades para controle de estoques em toda a rede (item 306 do relatório final de auditoria); 43) promover capacitação e conscientização dos servidores dos hospitais para correta utilização e Apresentação do Projeto Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br alimentação do software acima citado (item 306 do relatório final de auditoria); 56) estabelecer papéis e funções, definição de planos, políticas e procedimentos técnicos na área de Tecnologia da Informação, com a devida comunicação à toda organização da SESAP após a aprovação formal, devendo tais políticas seguir as normas e as boas práticas internacionais, especialmente a NBR ISO/IEC 27001, NBR ISO/IEC 27002, NBR ISO/IEC 15999, COBIT 4.1, ITIL V3, PMBOK, bem como as orientações constantes nos diversos acórdãos do TCU, tal como o Acórdão nº 111/2011-Plenário, itens 3.7, 3.8, 3.9, 3.10, 3.11, 3.14, 3.15, 3.16 e 3.17 (item 394 do relatório final de auditoria) 61) considerar outras formas de aquisição de sistemas, como a utilização de softwares gratuitos, convênios com outros estados, desenvolvimento de sistema próprio e até mesmo a compra de um sistema (item 431 do relatório final de auditoria); 62) rever o processo de implantação, instalação, treinamento e suporte do sistema de gestão hospitalar (SALUX), utilizando técnicas de gerenciamento de projetos, de forma a reduzir os riscos de insucesso na implantação e manutenção. (item 448 do relatório final de auditoria) 64) reestruturar proposta de implantação do complexo regulador, reavaliando os aspectos relacionados à Tecnologia da Informação, considerando o atual estágio de imaturidade dos servidores dos hospitais em tal área. Recomenda-se, ainda, que sejam utilizadas técnicas de gerenciamento de projetos, de forma a atingir os objetivos propostos dentro de parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos e custos. (item 464 do relatório final de auditoria) Diante do exposto, o patrocinador do projeto decidiu então criar umprojeto para implantação de um escritório de projetos (PMO) de modo a gerenciar a implementação e aplicação de uma metodologia de gestão de projetos para desenvolvimento de sistemas de informação, em especial o Sistema Integrado de Gestão de Informações Hospitalares a ser instalado em toda rede hospitalar do estado do Rio Grande do Norte, tal metodologia seria testada nos módulos iniciais e após seguidas correções poderia ser utilizada de forma definitiva no Escritório de Projetos para gerenciar o desenvolvimento desse sistema. 129 APENDICE D – DECLARAÇÃO DO ESCOPO DO PROJETO Declaração do Escopo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH DECLARAÇÃO DO ESCOPO SCOPE STATEMENT Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Ricardo Souza Lima – Patrocinador – Subcoordenador 02/09/2013 I - Patrocinador Ricardo de Souza Lima – Subcoordenador de Informação e Informática II - Nome do gerente do projeto, suas responsabilidades e sua autoridade Rodrigo Xavier Ferreira de Oliveira é o gerente do projeto. Sua autoridade é parcial na esfera da SUININ, podendo propor a contratação, realização de compras e gerenciamento de pessoal de acordo com seus critérios. Porém a execução estará basicamente atrelada ao aceite do patrocinador. No aspecto financeiro, a autoridade do gerente de projeto estará limitada a determinadas autonomias, a serem definidas no plano de gerenciamento de custos. No caso de necessidade de relacionamento externo à divisão, sua autoridade é a autoridade funcional inerente ao seu posto dentro da organização. III - Time do Projeto Rodrigo Xavier Programador George Carvalho Programador Flavio Cabral Programador Sergio Alexandre Programador Augusto Administrador de BD Denise Guerra Analista de Sistemas Francisco Carlos Manutenção Douglas Alberto Analista de Suporte Dolores Beutemuller Administrador de Redes Francisco Canindé Administrador de Redes Flávia Viana Hospitalar Fátima Honorato Aquisições Thiago Gondim Manutenção Altamir Processos IV - Descrição do Projeto O projeto envolverá o diagnóstico do ambiente, as compras de software e hardware, a criação de metodologia, o subprojeto piloto, o projeto final, a padronização de projetos e o treinamento do pessoal da SUININ. V - Objetivo do projeto Implementar o gerenciamento de projetos na SUININ através de um escritório de projetos (PMO), munido de metodologias de gerenciamento próprias de acordo com o perfil da organização e seus ativos processuais organizacionais para desenvolvimento de um Sistema Gestor Hospitalar a ser implantado em toda Rede Hospitalar no âmbito do estado do Rio grande do Norte, dentro de um prazo máximo de 1265 dias iniciando em setembro de 2013 e com um custo estimado de R$23.175,00. VI - Justificativa do projeto Ao mesmo tempo que visa atender à recomendações do Tribunal de Contas do Estado do Rio Grande do Norte, o projeto visa resolver os maiores problemas relacionados a sistemas gerenciais principalmente àqueles voltados à gestão hospitalar e regulação estadual implantando uma metodologia de gerenciamento de projetos em um escritório de projetos que será dedicado à equipe de desenvolvimento desta secretaria. VII - Produto do projeto Metodologia implementada e documentada com aprovação do patrocinador, bem como inicialmente um subprojeto-piloto implementado no setor para avaliar sua efetividade. Em seguida um projeto completo de sistema de gestão hospitalar a ser implantado na rede hospitalar estadual e nas unidades de referência. VIII - Expectativas  Projeto em conformidade com o Termo de Abertura ou Project Charter  Projeto dentro do prazo e do orçamento previsto IX - Fatores de sucesso do projeto  Comunicação efetiva dentro do time  Apoio integral da área de TI Declaração do Escopo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br  Suporte permanente do patrocinador X - Restrições  O orçamento é limitado e pré-estabelecido com baixíssima capacidade de amplitude.  O projeto deve ser mantido dentro do Nível Central, tendo apenas o contato externo com alguns hospitais de referência para entrevistas e sessões de brainstorming. XI - Premissas  As pessoas podem mudar seu comportamento se adequadamente estimuladas e preparadas.  A comunicação dentro do time será feita pessoalmente e através do Microsoft Project Server, cedido pela Microsoft.  É necessário o apoio irrestrito de todos os envolvidos dentro da SUININ.  Os membros do time terão dedicação integral ao projeto considerando as cargas horárias de cada um.  O time do projeto deverá ter conhecimento básico de gerenciamento de projetos e de informática. XII - Exclusões específicas  A equipe de consultoria atuará apenas como apoio, e não como mão-de-obra. XIII - Principais atividades e estratégias do projeto 1. Geral  O custo de pessoal mesmo fazendo parte do custo fixo da organização compõe o valor orçado.  Serão consideradas críticas as atividades com folga menor ou igual a 3 dias. 2. Diagnóstico  A metodologia será a do PMI através do Guia PMBOK Guide 2013.  É acompanhado por consultor especializado externo. 3. Treinamento  Prevê treinamento de software e metodologia de gerenciamento de projetos, inclusive para os usuários finais através dos Analistas de Sistemas e do Gerente de Projetos.  Os treinamentos serão realizados no próprio ambiente de trabalhoquando necessário.  As máquinas utilizadas no treinamento já serão as definitivas da equipe. 4. Software  6 licenças do Microsoft Project 2010 Professional com Microsoft Project Web Access para todas as máquinas  1 licença do Microsoft Project 2010 Server como servidor de projetos  SQL Server 2008 como plataforma de banco de dados no servidor  1 licença Windows Server 2008 R2 Datacenter.  12 licenças Windows 7 Professional para componentes da equipe.  Instalação realizada pela manutenção da SUININ.  Todos os programas serão fornecidos gratuitamente pelo fabricante para fins de pesquisa e extensão. 5. Hardware  1 Servidor Xeon 3,2ghz com 6GB de Memória RAM, 4 HD’s espelhados com 500 GB (incluindo Backup) cada.  6 Microcomputadores Intel Dual Core 2GHz com 2Gb de Memória RAM, HD de 320 GB e rede.  Instalação realizada pela manutenção da SUININ. 6. Piloto  Duração máxima de 6 meses de execução.  Realização exclusiva da SESAP/SUININ.  Avaliação de resultados incluindo o patrocinador. 7. Padronização  Inclusão de padronização de projetos, relatórios, modos de exibição, todos disponíveis através do http://pmo.saude.rn.gov.br  Confecção dos padrões realizada completamente pela SUININ  Padrões aprovados pelo gerente de projeto, gestor imediato e patrocinador Declaração do Escopo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br XIV - Entregas do projeto  Subprojeto-Piloto SIGIH o Instalação do Escritório concluído  Aquisição de computadores concluído;  Definição de sala situação concluído;  Transferência inicial de pessoal concluído;  Definição da metodologia concluído; o Módulo de dados concluído:  Análise de sistema inicial dos módulos concluído;  Definição de linguagens de programação concluído;  Análise documental da base de dados concluído;  Definição de heranças e dependências concluído;  Criar tabelas e campos concluído;  Normalização da base de dados concluído;  Integração da base de dados ao ORM concluído;  Configuração e Sincronização do controle de versão concluído.  Complemento Projeto SIGIH o Módulo Subprojeto Piloto PMO e Base de Dados concluído; o Módulo Cadastro/Administração concluído; o Módulo Regulador concluído; o Módulo Recepção/Apoio SADT concluído; o Módulo Almoxarifado/Farmácia/Estoque concluído; o Módulo Rouparia/Higienização concluído; o Módulo Leitos/Internação/Alta concluído; o Módulo Prontuário Eletrônico/Arquivo Médico concluído; o Módulo Enfermagem concluído; o Módulo Ambulatorial/Emergência concluído; o Módulo Pronto Socorro concluído; o Módulo Centro Cirúrgico concluído; o Módulo Nutrição/Dietética concluído. XV - Orçamento do projeto  O projeto prevê um gasto de até R$1.000.000, excluindo as reservas gerenciais para o projeto piloto, para os demais projetos R$1.000.000.  As reservas gerenciais e de contingência somadas durante cada etapa não podem ultrapassar 10% do orçamento de cada etapa.  O pagamento dos valores adicionais orçados se efetuará segundo o fluxo de caixa a ser desenvolvido para o projeto e aprovado pelo patrocinador.  As despesas com pessoal e recursos internos já estão sendo consideradas dentro do orçamento do projeto e continuarão a ser efetuadas de acordo com o financeiro da SESAP alimentando o fluxo de caixa do projeto.  Antecipações ou atrasos não deslocam o fluxo de caixa do projeto. XVI - Plano de entregas e marcos do projeto A execução dos trabalhos terá início em setembro de 2013 e deve durar aproximadamente 78 meses. O subprojeto-piloto terá execução iniciada em setembro de 2013 e deve durar aproximadamente 6 meses. O planejamento do projeto, bem como sua finalização deverão ser realizadas dentro do período descrito para cada fase. Para cada subprojeto, deve-se refazer a Declaração do Projeto para reconstruir o cronograma abaixo representado em cada subprojeto; ao final deve-se apresentar a versão de cronograma do projeto completo atualizado. Projeto Piloto SIGIH – Módulo PMO e Base de Dados ENTREGA DESCRIÇÃO TÉRMINO Iniciação Gerente do Projeto Definido Project Charter Aprovado Planejamento Scope Statement Aprovado Cronograma definido Declaração do Escopo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br Orçamento definido Plano do Projeto Concluído Aprovação do Plano do Projeto Execução Aquisição de computadores concluído Definição de sala situação concluído Transferência inicial de pessoal concluído Definição da metodologia concluído Análise de sistema inicial dos módulos concluído Definição de linguagens de programação concluído Análise documental da base de dados concluído Definição de heranças e dependências concluído Criar tabelas e campos concluído Normalização da base de dados concluído Encerramento Projeto concluído Lições aprendidas registradas Complemento Projeto SIGIHÇÕES ENTREGA DESCRIÇÃO TÉRMINO Iniciação Gerente do Projeto Definido Project Charter Aprovado Planejamento Scope Statement Aprovado Cronograma definido Orçamento definido Plano do Projeto Concluído Aprovação do Plano do Projeto Execução Módulo Cadastro/Administração concluído Módulo Regulador concluído Módulo Recepção/Apoio SADT concluído Módulo Almoxarifado/Farmácia/Estoque concluído Módulo Rouparia/Higienização concluído Módulo Leitos/Internação/Alta concluído Módulo Prontuário Eletrônico/Arquivo Médico concluído Módulo Enfermagem concluído Módulo Ambulatorial/Emergência concluído Módulo Pronto Socorro concluído Módulo Centro Cirúrgico concluído Módulo Nutrição/Dietética concluído Encerramento Projeto concluído Lições aprendidas registradas REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA 27/08/2013 Ricardo Souza Lima Detalhamento do orçamento aproximado 30/08/2013 Rodrigo Xavier F. de Oliveira Especificações de software e hardware 02/09/2013 Rodrigo Xavier F. de Oliveira Atualização dos términos das entregas APROVAÇÕES Ricardo Souza Lima Patrocinador Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 134 APENDICE E – TERMO DE ABERTURA DO PROJETO Termo de Abertura do Projeto Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH TERMO DE ABERTURA DO PROJETO PROJECT CHARTER Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Ricardo Souza Lima – Patrocinador – Subcoordenador 02/09/2013 I - Resumo das condições do projeto A divisão de desenvolvimento de sistemas da SESAP/CPCS/SUININ decidiu criar um projeto para implantação de um escritório de projetos (PMO) de modo a gerenciar a implementação e aplicação de uma metodologia de gestão de projetos para desenvolvimento de sistemas de informação, em especial o Sistema Integrado de Gestão de Informações Hospitalares a ser instalado em toda rede hospitalar do estado do Rio Grande do Norte, tal metodologia seria testada nos módulos iniciais e após seguidas correções poderia ser utilizada de forma definitiva no Escritório de Projetos para gerenciar o desenvolvimento desse sistema. Nunca antes houve a tentativa de se implementar um gerenciamento de projetos na unidade, o setor de programação de sistemas trabalhava de forma autônoma sem chefia imediata e sem demandas específicas com prazos estipulados, toda a equipe da SUININ foi renovada através dos últimos concursos públicos de 2008 e 2010, o conhecimento técnico da equipe é certificado porém não se sabe como os servidores se comportarão trabalhando em equipe. II - Nome do gerente do projeto, suas responsabilidades e autoridade Rodrigo Xavier Ferreira de Oliveira é o gerente do projeto. Sua autoridade é parcial na esfera da SUININ, podendo propor a contratação, realização de compras e gerenciamento de pessoal de acordo com seus critérios. Porém a execução estará basicamente atrelada ao aceite do patrocinador. No aspecto financeiro, a autoridade do gerente de projeto estará limitada a determinadas autonomias, a serem definidas no plano de gerenciamento de custos. No caso de necessidade de relacionamento externo à divisão, sua autoridade é a autoridade funcional inerente ao seu posto dentro da organização. III - Necessidades básicas do trabalho a ser realizado Serão realizadas aquisições de software e hardware, a criação de metodologia, projeto piloto e padronização de projetos, bem como o treinamento do pessoal da SUININ. IV - Descrição do projeto 1. Produto do projeto Metodologia implementada e documentada com aprovação do patrocinador, bem como um subprojeto-piloto contido em um projeto-pai implementado na divisão para avaliar a efetividade da metodologia. 2. Cronograma básico do projeto A execução dos trabalhos no subprojeto-piloto terá início em setembro de 2013 e deve durar aproximadamente 110 dias. A execução dos trabalhos em todo o projeto terá início em setembro de 2013 e deve durar aproximadamente 1265 dias. Termo de Abertura do Projeto Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br 3. Estimativas iniciais de custo O orçamento para este projeto é de R$ 23.175,00 de gastos adicionais da SUININ (custos internos não serão considerados). V - Administração 1. Necessidade inicial de recursos O gerente terá uma equipe de 13 profissionais, podendo, ainda, contratar externos para o projeto. Máquinas e equipamentos precisarão ser adquiridos. 2. Necessidade de suporte pela organização A organização irá suportar toda a necessidade externa à divisão, uma vez que existe um interesse de longo prazo em implementar o gerenciamento de projetos em outras áreas. 3. Controle e gerenciamento das informações do projeto O gerente de projeto é o responsável pelas informações. Todas as informações devem ser armazenadas em banco de dados e acessadas através do site http://pmo.saude.rn.gov.br. APROVAÇÕES Ricardo Souza Lima Patrocinador Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 137 APENDICE F – PLANO DE GERENCIAMENTO DE ESCOPO Plano de Gerenciamento de Escopo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DO ESCOPO SCOPE MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira - Gerente do Projeto 02/09/2013 I – Descrição dos processos de gerenciamento de escopo  O gerenciamento do escopo do projeto será realizado com base em dois documentos específicos: Declaração de escopo para o escopo funcional do projeto e WBS para o escopo das atividades a serem realizadas pelo projeto, com suas devidas entregas.  Devem ser fornecidos todos os entregáveis descritos na EAP do projeto.  Todas as mudanças no escopo inicialmente previsto para o projeto devem ser avaliadas e classificadas dentro do sistema de controle de mudanças de escopo (Scope Change Control System).  Serão consideradas mudanças de escopo apenas as medidas corretivas. Inovações e novas características do produto/projeto não serão consideradas pelo gerenciamento de escopo.  Todas as solicitações de mudança no escopo devem ser feitas por escrito ou através de e-mail, conforme descrito no plano de comunicações do projeto. II - Priorização das mudanças de escopo e respostas As solicitações de alteração de escopo deverão ser registradas em formulário próprio, escrito ou através de e-mail como previsto no PGC e armazenadas em formato físico na pasta do projeto. Uma cópia digitalizada deve ser armazenada em pasta eletrônica dentro da área do projeto. As mudanças de escopo são classificadas em quatro níveis de prioridades  0 (zero) – Requer uma ação imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador, uma vez que se trata de mudança urgente, de alto impacto no projeto e em outras áreas sobre as quais o gerente de projeto não tem autonomia.  1 (um) - Requer uma ação imediata por parte do gerente do projeto, independente das reuniões de controle previstas devido à urgência, acionando imediatamente o patrocinador no caso de necessidade de autorizações financeiras fora da alçada do gerente de projetos.  2 (dois) – Requer um planejamento da ação através de terceiros ou de equipes que, a princípio, tenham disponibilidade, uma vez que agregam valor ao sucesso do projeto e são urgentes, porém não têm impacto significativo nos custos e nos prazos do projeto.  3 (três) –Podem ser implementadas por terem influência no sucesso do projeto, porém não requerem uma ação imediata por não serem impactantes ou urgentes. III – Sistema de Controle de Mudanças do Escopo O sistema de controle de mudanças de escopo deve proporcionar com que todas as mudanças no escopo do projeto sejam tratadas segundo o fluxo apresentado a seguir com seus resultados apresentados na reunião semanal da equipe com suas conclusões, prioridades e ações relacionadas. Plano de Gerenciamento de Escopo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br IV - Frequência de avaliação do escopo do projeto O escopo do projeto deve ser avaliado semanalmente dentro da reunião da equipe de desenvolvimento da SUININ. V - Alocação financeira das mudanças de escopo As mudanças de escopo corretivas podem ser alocadas dentro das reservas gerenciais do projeto, desde que dentro da alçada do gerente de projeto, nos limites definidos no PGC para dispensa de licitação em serviços e aquisições de equipamentos. Para mudanças de escopo corretivas prioritárias que estejam fora da alçada do gerente de projeto, ou quando não existe mais reserva gerencial disponível (exceder o limite da dispensa), deverá ser acionado o patrocinador. VI - Administração do plano de gerenciamento de escopo 1. Responsável pelo plano • Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento de escopo. • Rodrigo Xavier, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento de escopo. 2. Freqüência de atualização do plano de gerenciamento de escopo O plano de gerenciamento de escopo será reavaliado mensalmente na reunião mensal da equipe com o patrocinador, juntamente com os outros planos de gerenciamento do projeto. VII - Outros assuntos relacionados ao gerenciamento do escopo do projeto não previstos neste plano Todas as solicitações não previstas neste plano deverão ser submetidas a reunião semanal da equipe de projetos para aprovação. Imediatamente após sua aprovação, deverão ser submetidas ao patrocinador para autorização, atualizando o plano de gerenciamento de escopo com o devido registro das alterações a serem efetivadas. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA 27/08/2013 Ricardo Souza Lima Conclusão sobre a Administração 30/08/2013 Rodrigo Xavier F. de Oliveira Alteração na reunião da avaliação 02/09/2013 Rodrigo Xavier F. de Oliveira Atualização no fluxograma 05/09/2013 Ricardo Souza Lima Alteração na descrição dos processos APROVAÇÕES Rodrigo Xavier F. Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 140 APENDICE G – PLANO DE GERENCIAMENTO DE CRONOGRAMA/TEMPO Plano de Gerenciamento de Tempo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DO TEMPO SCHEDULE MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira – Gerente do Projeto 02/09/2013 I - Descrição dos processos de gerenciamento de tempo O gerenciamento de tempo será realizado a partir da alocação de percentual completo nas atividades do projeto através da utilização do Microsoft Project 2010 através de todas as máquinas do desenvolvimento da SUININ em comunicação com o servidor Sharepoint do MS Project Server instalado. A atualização dos prazos do projeto será realizada no Microsoft Project através da publicação na intranet e no site do projeto quando disponível dos seguintes relatórios:  Gráfico de Gantt;  Percentual completo;  Diagrama de marcos. Serão consideradas críticas todas as atividades com folga menor ou igual a 5 dias. Uma folga de 5 dias ou menos não será considerada como disponibilidade, devido a remanejamento de horas de trabalho no projeto. Todas as mudanças no prazo inicialmente previsto para o projeto devem ser avaliadas e classificadas dentro do sistema de controle de mudanças de tempo. Serão considerados atrasos os decorrentes de medidas corretivas, que, se influenciadoras do sucesso do projeto, deverão ser integradas ao plano. Inovações e novos recursos não serão abordados pelo gerenciamento de tempo e serão passíveis de negociação de prazos ou serão ignorados. A atualização da linha de base do projeto somente será permitida com autorização expressa do gerente de projeto e do patrocinador, sendo a linha de base anterior arquivada, documentada e publicada para fins de lições aprendidas. Todas as solicitações de mudança nos prazos previamente definidos deverão ser feitas em formulário próprio por escrito ou através de e-mail. II - Priorização das mudanças nos prazos As mudanças nos prazos são classificadas em quatro níveis de prioridade: Prioridade 0 (zero) – Atrasos de prioridade zero requerem uma ação imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador para discussão e análise, uma vez que é um problema urgente, de alto impacto no projeto e com soluções inicialmente não identificadas. Prioridade 1 (um) - Atrasos de prioridade um requerem uma ação imediata por parte do gerente do projeto, independente das reuniões de controle previstas devido à urgência, acionando as medidas de recuperação de prazos disponíveis, tais como o Fast Tracking, o Crashing, o trabalho em horas-extras, banco de horas e mutirão. Os custos que por ventura decorrerem dessas ações deverão ser alocados nas reservas gerenciais, conforme descrito a seguir. Prioridade 2 (dois) – Atrasos de prioridade dois requerem um replanejamento das atividades futuras, uma vez que o projeto ainda não completou 25% de conclusão. Prioridade 3 (três) – Atrasos de prioridade três são atrasos pequenos se comparados com a duração do projeto e podem ser remanejados sem necessariamente ser preciso replanejar ou acionar algum tipo de mecanismo de recuperação. III - Sistema de controle de mudanças de prazos Todas as mudanças nos prazos e atrasos/adiantamentos do projeto devem ser tratados segundo o fluxo a seguir, com suas conclusões, prioridades e ações relacionadas apresentadas na reunião semanal da equipe de desenvolvimento. Plano de Gerenciamento de Tempo Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br IV - Buffer de tempo do projeto O projeto não prevê a criação ou a determinação de uma folga ou margem de atraso no término do projeto baseado nos conceitos de corrente crítica, uma vez que a metodologia adotada na construção de cronogramas foi baseada no conceito de caminho crítico, e não no conceito de corrente crítica (Teoria das Restrições), mas será considerada um atraso máximo de 5 dias para delimitar o quão crítica é a mudança solicitada. V - Frequência de avaliação dos prazos do projeto Os prazos do projeto devem ser avaliados semanalmente dentro da reunião da equipe de desenvolvimento da SUININ. VI - Alocação financeira para o gerenciamento de tempo Todas as medidas de recuperação de atrasos no projeto que requererem gasto adicional deverão ser alocadas dentro das reservas gerenciais do projeto, desde que dentro da alçada do gerente de projeto nos limites definidos no PGC para dispensa de licitação em serviços e aquisições de equipamentos. Para medidas prioritárias para a recuperação de prazos que estejam fora da alçada do gerente de projeto, ou quando não existir mais reserva gerencial disponível (exceder o limite da dispensa), deverá ser acionado o patrocinador. VII - Administração do plano de gerenciamento de tempo 1. Responsável pelo plano • Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento de tempo. • Rodrigo Xavier, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento de tempo. 2. Freqüência de atualização do plano de gerenciamento de tempo O plano de gerenciamento de escopo será reavaliado mensalmente na reunião mensal da equipe com o patrocinador, juntamente com os outros planos de gerenciamento do projeto. VIII - Outros assuntos relacionados ao gerenciamento do tempo do projeto não previstos neste plano Todas as solicitações não previstas neste plano deverão ser submetidas a reunião semanal da equipe de projetos para aprovação. Imediatamente após sua aprovação, deverão ser submetidas ao patrocinador para autorização, atualizando o plano de gerenciamento de tempo com o devido registro das alterações a serem efetivadas. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA 27/08/2013 Ricardo Souza Lima Buffer de Tempo do Projeto APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. WBS ANALÍTICO SISTEMA GESTOR HOSPITALAR 3.2.Módulo Glaucoma 1.Modulo PMO e Base de Dados 3.2.1.Cadastro de Colírios 1.1.Instalação do Escritório 3.2.2.Fatores de Risco 1.1.1.Aquisição de Computadores e Infraestrutura 3.2.3.Consulta Inicial 1.1.2.Instalação de Sistemas 3.2.4.Ficha de Acompanhamento 1.1.3.Definição de Sala Situação 3.3.Implantação e Treinamento 1.1.4.Transferência de Pessoal 4.Modulo Recepção e SADT Agendamento 1.1.5.Definição da Metodologia 4.1.Recepção 1.2.Módulo Base de Dados 4.1.1.Boletim de Atendimento 1.2.1.Definir Linguagens de Programação 4.1.2.Acesso ao Cartão SUS 1.2.2.Análise Documental da Base de Dados 4.1.3.Alta do Paciente 1.2.3.Definir Heranças e Dependências 4.1.4.Impressos 1.2.4.Criar Tabelas e Campos 4.2.SADT Agendamento 1.2.5.Normalizar a Base de Dados 4.2.1.Assistente de Marcação 1.2.6.Integrar a Base de Dados ao ORM 4.3.Implantação e Treinamento 1.2.7.Configurar Controle Versão e Sincronizar 5.Modulo Estoque/Almox/Farmácia 1.2.8.Análise Inicial de Sistema dos Módulos 5.1.Estoque 2.Modulo Cadastros & Administração 5.1.1.CRUD Materiais Médico Hospitalares 2.1.Cadastros 5.1.2.CRUD Soluções e Medicamentos 2.1.1.Instituições 5.1.3.CRUD Locais de Estoque 2.1.2.Grupos de Usuários 5.1.4.CRUD Atendimento Horários e Relatór 2.1.3.Tipo de Profissional 5.1.5.Configurações de Estoque e MMMH 2.1.4.Especialidades 5.2.Almoxarifado 2.1.5.Hospitais 5.2.1.Dispensa de Materiais 2.1.6.Unidades 5.2.2.Controle de Estoque (MA) 2.1.7.Nacionalidades 5.2.3.ETBC de Materiais/Recebimento 2.1.8.Caráter de Atendimento 5.2.4.Solicitação de Material 2.1.9.Acomodações, Quartos e Leitos 5.3.Farmácia 2.1.10.Religiões 5.3.1.Preparação de Produtos / Dosagem 2.1.11.Motivos de Bloqueio 5.3.2.Dispensação/Solicitação/Prescrição 2.1.12.Transferência 5.3.3.Movimentações de Estoque MMMH 2.1.13.Graus de Parentesco 5.3.4.Encaminhamento e Entrega MM 2.1.14.Tipos de Anestesia 5.3.5.Impressão de Etiquetas 2.1.15.Vacinas 5.3.6.Relatórios 2.1.16.Sinais Vitais 5.4.Implantação e Treinamento 2.1.17.Graus de Participação 6.Modulo Rouparia & Higienização 2.2.Configurações 6.1.Rouparia 2.2.1.Acessos para Usuários 6.1.1.CRUD Peças e Kits 2.2.2.Acessos para Grupos 6.1.2.Estoque e Ajuste de Inventário 2.3.Implantação e Treinamento 6.1.3.Movimentações Internas e Externas 3.Modulo Regulação Estadual 6.1.4.Atendimento Agenda/Extra/Diário/Ativ 3.1.Módulo SUS Agendamento 6.1.5.Relatórios 3.1.1.CRUD Unidades S&R 6.2.Higienização 3.1.2.CRUD Usuários Pacientes e Médicos 6.2.1.CRUD Atividades de Limpeza 3.1.3.Interfaceamento SIGTAP 6.2.2.Atendimento Atividades Pontuais 3.1.4.Cadastro Critérios e Municípios 6.2.3.CRUD Períodos de Atividades 3.1.5.Prestador Agendamento/Baixa 6.2.4.Atendimento Gerência e Relatórios 3.1.6.Auditor Monitoramento 6.3.Implantação e Treinamento 3.1.7.Relatórios, Guias e APACs 7.Modulo Leitos/Internação/Alta 10.2.4.Agenda e Encaixe de Compromissos 7.1.CRUD Boletim de Internação 10.2.5.Transferência e Cancelamento 7.2.Gerenciamento de Óbitos 10.2.6.Relatórios 7.3.Gerenciamento de Alta Administrativa 10.3.Atendimento Médico Ambulatorial 7.4.Controle de Leitos 10.3.1.Interfaceamento Agendamentos 7.5.Transferência de Pacientes 10.3.2.Pré-Consulta e Sinais Vitais (P.E.) 7.6.Internação Cirúrgica 10.3.3.Interface de Impressão de Termos 7.7.Relatórios 10.3.4.Registro de Anamnese 7.8.Implantação e Treinamento 10.3.5.Acesso Gerar da Receita Médica (P.E.) 8.Modulo Pront. Eletrônico/Arq. Médico 10.3.6.Solicitar Exames e Procedimentos 8.1.Atendimento ao Paciente 10.3.7.Solicitação de Parecer Médico (P.E.) 8.1.1.Interface Prontuário Eletrônico 10.3.8.Documentos e Relatórios 8.1.2.Prescrição Médica 10.4.Implantação e Treinamento 8.1.3.Evolução do Paciente 11.Modulo Pronto Socorro 8.1.4.Parecer Médico 11.1.Recepção Pronto Socorro 8.1.5.Anamnese 11.1.1.Encaminhamentos Enfermagem 8.1.6.Exames Físicos 11.1.2.Interfaceamento Atendimento Ambulat 8.1.7.Oftalmologia 11.1.3.Internação e Transferência Externa 8.1.8.Receita Médica 11.1.4.Saída do Paciente/Alta Administrativa 8.1.9.Alergias 11.2.Atendimento de Enfermagem (P.S.) 8.1.10.Solicitações de Exames 11.2.1.Interfaceamento Avaliação Médica 8.2.Relatórios 11.2.2.Interface Enfermagem Ambulatorial 8.2.1.Fichas e Guias 11.2.3.Interface Cuidados Medic/Soluç/Proced 8.2.2.Prontuário Impresso 11.3.Atendimento Médico/Pronto Socorro 8.3.Implantação e Treinamento 11.3.1.Geração/Registro da Prescrição Médica 9.Modulo Enfermagem 11.3.2.Interfaceamento Atendimento 9.1.Interfaceamento Prescrição Eletrônica 11.3.3.Interfaceamento Consulta e Anamnese 9.2.Prescrição de Enfermagem 11.4.Implantação e Treinamento 9.3.Administração de Medicamentos 12.Modulo Centro Cirúrgico 9.4.Recebimento e Baixa de MMMH 12.1.Agendamento Cirúrgico 9.5.Interfaceamento MM Farmácia/Almoxarifado 12.1.1.Inclusão Profissional Paciente e Conv 9.6.Interfaceamento Transferência Leitos 12.1.2.Inclusão Procedimento Cirúrgico 9.7.Movimentação do Prontuário Paciente 12.1.3.Inclusão Porte Cirúrgico 9.8.Relatórios 12.1.4.Inclusão Equipamentos 9.9.Implantação e Treinamento 12.1.5.Inclusão Descrição Cirúrgica 10.Modulo Ambulatorial & Emergência 12.1.6.Inclusão de Alergias 10.1.Atendimento Ambulatorial 12.2.Cadastros de Parâmetros 10.1.1.Interface Recepção Pacientes Agendados 12.2.1.CRUD Kits Cirúrgicos 10.1.2.Confirmação de Agendamentos 12.2.2.Equipamentos e Motivos 10.1.3.Interfaceamento Cadastro Paciente 12.2.3.Descrição Cirúrgica 10.1.4.Interfaceamento CADWEB 12.2.4.Tipos e Classificação de Cirurgias 10.1.5.Criação do Prontuário Paciente 12.2.5.Posicionamento e Porte Cirúrgico 10.1.6.CRUD Boletim Atendimento 12.2.6.Grupos de Anestésicos e Salas 10.1.7.Interface Confirmar Procedimento 12.3.Criação Folhas de Sala 10.1.8.Interface Confirmar Boletim Ambulatorial 12.3.1.Inclusão/Exclusão de Soluções 10.1.9.Etiquetas Fichas Termos e Relatórios 12.3.2.Inclusão/Exclusão de Procedimentos 10.2.Agendamento Ambulatorial 12.3.3.Inclusão/Exclusão de MMMH 10.2.1.CRUD Tipos de Agendas 12.3.4.Inclusão/Exclusão de Taxas 10.2.2.Marcação de Compromisso 12.3.5.Lançamentos de OPM Especiais 10.2.3.Interface de Pesquisa de Horários 12.3.6.Emissão de Mapa Cirúrgico 12.3.7.Relatórios 12.4.Implantação e Treinamento 13.Modulo Nutrição & Dietética 13.1.Interfaceamento Prescrição Médica 13.2.CRUD Refeições 13.3.Cadastro de Dietas de Pacientes 13.4.Cadastro de Refeição para Acompanhantes 13.5.Baixa e Confecção Refeições e Dietas 13.6.Relatórios Recibos Dietas a Confeccionar 13.7.Implantação e Treinamento 146 WBS GRÁFICO PARTE 1 147 WBS GRÁFICO PARTE 2 148 GRÁFICO DE GANTT PARTE 1 149 GRÁFICO DE GANTT PARTE 2 NOME DA ATIVIDADE DUR NOME DA ATIVIDADE DUR SISTEMA GESTOR HOSPITALAR 1265 dias 3.1.7.Relatórios, Guias e APACs 3 sems 1.Modulo PMO e Base de Dados 110 dias 3.2.Módulo Glaucoma 35 dias 1.1.Instalação do Escritório 60 dias 3.2.1.Cadastro de Colírios 1 sem 1.1.1.Aquisição de Computadores e Infraestrut 1 mês 3.2.2.Fatores de Risco 1 sem 1.1.2.Instalação de Sistemas 1 mês 3.2.3.Consulta Inicial 2 sems 1.1.3.Definição de Sala Situação 2 meses 3.2.4.Ficha de Acompanhamento 2 sems 1.1.4.Transferência de Pessoal 3 meses 3.3.Implantação e Treinamento 2 sems 1.1.5.Definição da Metodologia 3 meses 4.Modulo Recepção e SADT Agendamento 60 dias 1.2.Módulo Base de Dados 50 dias 4.1.Recepção 35 dias 1.2.1.Definir Linguagens de Programação 2 sems 4.1.1.Boletim de Atendimento 3 sems 1.2.2.Análise Documental da Base de Dados 2 sems 4.1.2.Acesso ao Cartão SUS 1 sem 1.2.3.Definir Heranças e Dependências 2 sems 4.1.3.Alta do Paciente 2 sems 1.2.4.Criar Tabelas e Campos 2 sems 4.1.4.Impressos 1 sem 1.2.5.Normalizar a Base de Dados 1 sem 4.2.SADT Agendamento 25 dias 1.2.6.Integrar a Base de Dados ao ORM 1 sem 4.2.1.Assistente de Marcação 3 sems 1.2.7.Configurar Controle Versão e Sincronizar 1 sem 4.3.Implantação e Treinamento 2 sems 1.2.8.Análise Inicial de Sistema dos Módulos 4 sems 5.Modulo Estoque/Almox/Farmácia 150 dias 2.Modulo Cadastros & Administração 110 dias 5.1.Estoque 60 dias 2.1.Cadastros 80 dias 5.1.1.CRUD Materiais Médico Hospitalares 3 sems 2.1.1.Instituições 2 sems 5.1.2.CRUD Soluções e Medicamentos 3 sems 2.1.2.Grupos de Usuários 3 sems 5.1.3.CRUD Locais de Estoque 3 sems 2.1.3.Tipo de Profissional 2 sems 5.1.4.CRUD Atendimento Horários e Relatórios 3 sems 2.1.4.Especialidades 2 sems 5.1.5.Configurações de Estoque e MMMH 2 sems 2.1.5.Hospitais 2 sems 5.2.Almoxarifado 40 dias 2.1.6.Unidades 2 sems 5.2.1.Dispensa de Materiais 2 sems 2.1.7.Nacionalidades 1 sem 5.2.2.Controle de Estoque (MA) 2 sems 2.1.8.Caráter de Atendimento 1 sem 5.2.3.ETBC de Materiais/Recebimento 2 sems 2.1.9.Acomodações, Quartos e Leitos 3 sems 5.2.4.Solicitação de Material 2 sems 2.1.10.Religiões 1 sem 5.3.Farmácia 50 dias 2.1.11.Motivos de Bloqueio 2 sems 5.3.1.Preparação de Produtos / Dosagem 2 sems 2.1.12.Transferência 2 sems 5.3.2.Dispensação/Solicitação/Prescrição 2 sems 2.1.13.Graus de Parentesco 1 sem 5.3.3.Movimentações de Estoque MMMH 2 sems 2.1.14.Tipos de Anestesia 2 sems 5.3.4.Encaminhamento e Entrega MM 2 sems 2.1.15.Vacinas 2 sems 5.3.5.Impressão de Etiquetas 1 sem 2.1.16.Sinais Vitais 2 sems 5.3.6.Relatórios 3 sems 2.1.17.Graus de Participação 2 sems 5.4.Implantação e Treinamento 2 sems 2.2.Configurações 30 dias 6.Modulo Rouparia & Higienização 100 dias 2.2.1.Acessos para Usuários 2 sems 6.1.Rouparia 50 dias 2.2.2.Acessos para Grupos 2 sems 6.1.1.CRUD Peças e Kits 3 sems 2.3.Implantação e Treinamento 2 sems 6.1.2.Estoque e Ajuste de Inventário 2 sems 3.Modulo Regulação Estadual 115 dias 6.1.3.Movimentações Internas e Externas 1 sem 3.1.Módulo SUS Agendamento 80 dias 6.1.4.Atendimento Agenda/Extra/Diário/Ativ 2 sems 3.1.1.CRUD Unidades S&R 3 sems 6.1.5.Relatórios 2 sems 3.1.2.CRUD Usuários Pacientes e Médicos 3 sems 6.2.Higienização 50 dias 3.1.3.Interfaceamento SIGTAP 2 sems 6.2.1.CRUD Atividades de Limpeza 3 sems 3.1.4.Cadastro Critérios e Municípios 2 sems 6.2.2.Atendimento Atividades Pontuais 2 sems 3.1.5.Prestador Agendamento/Baixa 2 sems 6.2.3.CRUD Períodos de Atividades 3 sems 3.1.6.Auditor Monitoramento 3 sems 6.2.4.Atendimento Gerência e Relatórios 2 sems 6.3.Implantação e Treinamento 2 sems 10.2.2.Marcação de Compromisso 1 sem 7.Modulo Leitos/Internação/Alta 85 dias 10.2.3.Interface de Pesquisa de Horários 1 sem 7.1.CRUD Boletim de Internação 3 sems 10.2.4.Agenda e Encaixe de Compromissos 1 sem 7.2.Gerenciamento de Óbitos 2 sems 10.2.5.Transferência e Cancelamento 1 sem 7.3.Gerenciamento de Alta Administrativa 2 sems 10.2.6.Relatórios 2 sems 7.4.Controle de Leitos 2 sems 10.3.Atendimento Médico Ambulatorial 65 dias 7.5.Transferência de Pacientes 2 sems 10.3.1.Interfaceamento Agendamentos 1 sem 7.6.Internação Cirúrgica 2 sems 10.3.2.Pré-Consulta e Sinais Vitais (P.E.) 2 sems 7.7.Relatórios 2 sems 10.3.3.Interface de Impressão de Termos 1 sem 7.8.Implantação e Treinamento 2 sems 10.3.4.Registro de Anamnese 1 sem 8.Modulo Pront. Eletrônico/Arq. Médico 90 dias 10.3.5.Acesso Geração da Receita Médica (PE) 2 sems 8.1.Atendimento ao Paciente 60 dias 10.3.6.Solicitar Exames e Procedimentos 1 sem 8.1.1.Interface Prontuário Eletrônico 2 sems 10.3.7.Solicitação de Parecer Médico (P.E.) 2 sems 8.1.2.Prescrição Médica 2 sems 10.3.8.Documentos e Relatórios 2 sems 8.1.3.Evolução do Paciente 2 sems 10.4.Implantação e Treinamento 2 sems 8.1.4.Parecer Médico 2 sems 11.Modulo Pronto Socorro 75 dias 8.1.5.Anamnese 2 sems 11.1.Recepção Pronto Socorro 35 dias 8.1.6.Exames Físicos 2 sems 11.1.1.Encaminhamentos Enfermagem 2 sems 8.1.7.Oftalmologia 2 sems 11.1.2.Interfaceamento Atendimento Ambul 1 sem 8.1.8.Receita Médica 2 sems 11.1.3.Internação e Transferência Externa 2 sems 8.1.9.Alergias 2 sems 11.1.4.Saída do Paciente/Alta Administrativa 2 sems 8.1.10.Solicitações de Exames 2 sems 11.2.Atendimento de Enfermagem (P.S.) 15 dias 8.2.Relatórios 30 dias 11.2.1.Interfaceamento Avaliação Médica 1 sem 8.2.1.Fichas e Guias 2 sems 11.2.2.Interface Enfermagem Ambulatorial 1 sem 8.2.2.Prontuário Impresso 2 sems 11.2.3.Interface Cuidados Medic/Soluç/Proc 1 sem 8.3.Implantação e Treinamento 2 sems 11.3.Atendimento Médico/Pronto Socorro 25 dias 9.Modulo Enfermagem 110 dias 11.3.1.Geração/Registro da Prescrição Méd 2 sems 9.1.Interfaceamento Prescrição Eletrônica 2 sems 11.3.2.Interfaceamento Atendimento 1 sem 9.2.Prescrição de Enfermagem 3 sems 11.3.3.Interfaceamento Consulta e Anamnese 1 sem 9.3.Administração de Medicamentos 3 sems 11.4.Implantação e Treinamento 2 sems 9.4.Recebimento e Baixa de MMMH 3 sems 12.Modulo Centro Cirúrgico 130 dias 9.5.Interfaceamento MM Farmácia/Almoxarifado 2 sems 12.1.Agendamento Cirúrgico 20 dias 9.6.Interfaceamento Transferência Leitos 2 sems 12.1.1.Inclusão Profissional Paciente e Conv 1 sem 9.7.Movimentação do Prontuário Paciente 3 sems 12.1.2.Inclusão Procedimento Cirúrgico 1 sem 9.8.Relatórios 2 sems 12.1.3.Inclusão Porte Cirúrgico 1 sem 9.9.Implantação e Treinamento 2 sems 12.1.4.Inclusão Equipamentos 1 sem 10.Modulo Ambulatorial & Emergência 180 dias 12.1.5.Inclusão Descrição Cirúrgica 1 sem 10.1.Atendimento Ambulatorial 70 dias 12.1.6.Inclusão de Alergias 1 sem 10.1.1.Interface Recepção Pacientes Agendados 2 sems 12.2.Cadastros de Parâmetros 60 dias 10.1.2.Confirmação de Agendamentos 2 sems 12.2.1.CRUD Kits Cirúrgicos 3 sems 10.1.3.Interfaceamento Cadastro Paciente 2 sems 12.2.2.Equipamentos e Motivos 2 sems 10.1.4.Interfaceamento CADWEB 2 sems 12.2.3.Descrição Cirúrgica 2 sems 10.1.5.Criação do Prontuário Paciente 3 sems 12.2.4.Tipos e Classificação de Cirurgias 1 sem 10.1.6.CRUD Boletim Atendimento 3 sems 12.2.5.Posicionamento e Porte Cirúrgico 2 sems 10.1.7.Interface Confirmar Procedimento 1 sem 12.2.6.Grupos de Anestésicos e Salas 2 sems 10.1.8.Interface Confirmar Boletim Ambulatorial 1 sem 12.3.Criação Folhas de Sala 50 dias 10.1.9.Etiquetas Fichas Termos e Relatórios 2 sems 12.3.1.Inclusão/Exclusão de Soluções 1 sem 10.2.Agendamento Ambulatorial 45 dias 12.3.2.Inclusão/Exclusão de Procedimentos 1 sem 10.2.1.CRUD Tipos de Agendas 3 sems 12.3.3.Inclusão/Exclusão de MMMH 1 sem 12.3.4.Inclusão/Exclusão de Taxas 1 sem 12.3.5.Lançamentos de OPM Especiais 2 sems 12.3.6.Emissão de Mapa Cirúrgico 2 sems 12.3.7.Relatórios 2 sems 12.4.Implantação e Treinamento 2 sems 13.Modulo Nutrição & Dietética 60 dias 13.1.Interfaceamento Prescrição Médica 1 sem 13.2.CRUD Refeições 3 sems 13.3.Cadastro de Dietas de Pacientes 2 sems 13.4.Cadastro de Refeição para Acompanhantes 2 sems 13.5.Baixa e Confecção Refeições e Dietas 2 sems 13.6.Relatórios Recibos Dietas a Confeccionar 2 sems 13.7.Implantação e Treinamento 2 sems 153 APENDICE H – PLANO DE GERENCIAMENTO DA QUALIDADE Plano de Gerenciamento da Qualidade Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DA QUALIDADE QUALITY MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira – Gerente do Projeto 02/09/2013 I - Descrição dos processos de gerenciamento da qualidade • Todas as reclamações provenientes de clientes, bem como produtos e/ou entregas não conformes com a declaração de escopo deverão ser tratados como medidas corretivas no plano de gerenciamento da qualidade. • Todas as mudanças nos requisitos de qualidade inicialmente previstas para o projeto devem ser avaliadas e classificadas dentro do sistema de controle de mudanças de qualidade. • Serão consideradas mudanças nos padrões de qualidade apenas as medidas corretivas, que, se influenciadoras no sucesso do projeto, devem ser integradas ao plano. Inovações e novos níveis de qualidade não serão considerados pelo gerenciamento da qualidade. • Todas as solicitações de mudança na qualidade devem ser feitas por escrito ou através de e-mail, conforme descrito no plano de comunicações do projeto. II - Priorização das mudanças nos quesitos de qualidade e respostas As mudanças dos requisitos de qualidade são classificadas em quatro níveis de prioridade: Prioridade 0 (zero) – Mudanças de prioridade zero requerem uma ação imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador, uma vez que se trata de mudança urgente, de alto impacto no projeto e em outras áreas sobre as quais o gerente de projeto não tem autonomia. Prioridade 1 (um) - Mudanças de prioridade um requerem uma ação imediata por parte do gerente do projeto, independente das reuniões de controle previstas devido à urgência, acionando imediatamente o patrocinador no caso de necessidade de autorizações financeiras fora da alçada do gerente de projetos. Prioridade 2 (dois) – Mudanças de prioridade dois requerem um planejamento da ação através de terceiros ou de equipes que, a princípio, tenham disponibilidade, uma vez que agregam valor ao sucesso do projeto e são urgentes, porém não têm impacto significativo nos custos e nos prazos do projeto. Prioridade 3 (três) – Mudanças de prioridade três podem ser implementadas por terem influência no sucesso do projeto, porém não requerem uma ação imediata por não serem impactantes ou urgentes. III - Sistema de controle de mudanças da qualidade Todas as mudanças na qualidade do projeto devem ser tratadas segundo o fluxo apresentado a seguir com suas conclusões apresentadas na reunião semanal da equipe com suas conclusões, prioridades e ações relacionadas. Plano de Gerenciamento da Qualidade Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br IV - Freqüência de avaliação dos requisitos de qualidade do projeto Os requisitos da qualidade do projeto devem ser avaliados semanalmente dentro da reunião da equipe do projeto, prevista no plano de gerenciamento das comunicações. V - Alocação financeira das mudanças nos requisitos de qualidade As mudanças na qualidade podem ser alocadas dentro das reservas gerenciais do projeto, na categoria Outras reservas, desde que dentro da alçada do gerente de projeto. Para mudanças prioritárias na qualidade que estejam fora da alçada do gerente de projeto, ou quando não existe mais reserva gerencial disponível, deverá ser acionado o patrocinador, já que o gerente de projeto não tem autonomia necessária para decidir utilizar a reserva de contingência para mudanças na qualidade. VI - Administração do plano de gerenciamento da qualidade 1. Responsável pelo plano • Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento da qualidade. • Rodrigo Xavier F. de Oliveira, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento da qualidade. 2. Frequência de atualização do plano de gerenciamento da qualidade O plano de gerenciamento da qualidade será reavaliado mensalmente na reunião mensal da equipe com o patrocinador, juntamente com os outros planos de gerenciamento do projeto. VIII - Outros assuntos relacionados ao gerenciamento da qualidade do projeto não previstos neste plano Todas as solicitações não previstas neste plano deverão ser submetidas a reunião semanal da equipe de projetos para aprovação. Imediatamente após sua aprovação, deverão ser submetidas ao patrocinador para autorização, atualizando o plano de gerenciamento da qualidade com o devido registro das alterações a serem efetivadas. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 156 APENDICE I – PLANO DE GERENCIAMENTO DE CUSTOS/ORÇAMENTO Plano de Gerenciamento de Custos Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DE CUSTOS COST MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier Ferreira de Oliveira – Gerente do Projeto 02/09/2013 I - Descrição dos processos de gerenciamento de custos  A atualização do orçamento do projeto será realizada no Microsoft Project através da publicação no site do projeto do relatório de acompanhamento do orçamento.  O gerenciamento de Custos do projeto será executado apenas para acompanhamento do desenrolar das atividades, um vez que os custos e orçamento do projeto são engessados e pouco escaláveis.  O gerenciamento de custos do projeto será realizado com base no orçamento previsto para o projeto (subdividido por tarefas e por recursos), bem como através do fluxo de caixa do projeto apenas para compreender e acompanhar o rendimento da equipe.  Somente serão contempladas pelo plano de gerenciamento de custos as despesas adicionais provenientes de compras e contratações externas. Os custos relativos ao pessoal e aos recursos internos não serão contabilizados no projeto assim como os recursos obtidos através de doações e cessões temporárias.  Questões de caráter inflacionário e cambial serão desconsideradas dentro do período de tempo do projeto.  Todas as mudanças no orçamento inicialmente previstas para o projeto devem ser avaliadas e classificadas dentro do sistema de controle de mudanças de orçamento (Cost Change Control System).  Serão consideradas mudanças orçamentárias apenas as medidas corretivas. Inovações e novas características do produto/projeto não serão abordadas pelo gerenciamento de custos e serão ignoradas.  Todas as solicitações de verbas devem ser feitas por escrito em formulário próprio ou através de e-mail. II - Freqüência de avaliação do orçamento do projeto e das reservas gerenciais  O orçamento do projeto deve ser atualizado e avaliado diariamente, sendo os resultados publicados na intranet e no site do projeto quando disponível e apresentados na reunião semanal da equipe de desenvolvimento da SUININ.  As reservas devem ser avaliadas semanalmente, e os resultados e saldo, apresentados na reunião semanal da equipe de desenvolvimento da SUININ. III - Reservas gerenciais Foi aprovada pelo patrocinador uma reserva gerencial total de R$30.000,00 (trinta mil reais). As reservas gerenciais se subdividem em Reservas de Aquisição e Reservas de Serviço, que, juntamente com o orçamento do projeto, compõem o custo final do projeto. Nenhum percentual final de sobra será distribuído para a equipe a título de premiação. IV - Autonomias O gerente de projeto tem as seguintes autonomias quanto à utilização das reservas: Reservas de Aquisição Reservas de Serviço Gerente de projetos isoladamente R$ 0,00 R$ 0,00 Gerente de projetos com aval do patrocinador R$ 8.000,00 R$ 15.000,00 Patrocinador exclusivamente Acima de R$ 8.000,00 Acima de R$ 15.000,00  Essa autonomia é por cada solicitação de mudanças proveniente dos outros planos, podendo o gerente de projeto consumir a reserva, desde que em diferentes solicitações.  Com o fim das reservas, somente o patrocinador poderá solicitar e decidir sobre a criação de novas reservas conforme será apresentado a seguir neste plano. Plano de Gerenciamento de Custos Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br  Conforme descrito no plano de gerenciamento de recursos humanos, não haverá premiação para a equipe em valores monetários ao final do projeto.  A utilização da intervenção exclusiva do patrocinador em utilizar a reserva fora da faixa permitida ao gerente de projetos (terceira situação) implica em mudança drástica no Gerenciamento de Tempo do Projeto, devendo ser revista a solicitação e procuradas alternativas urgentes. V - Alocação financeira para o gerenciamento de custos As mudanças de caráter corretivo podem ser alocadas dentro das reservas gerenciais do projeto, desde que dentro da alçada do gerente de projeto nos limites definidos no PGC para dispensa de licitação em serviços e aquisições de equipamentos. Para medidas corretivas prioritárias que estejam fora da alçada do gerente de projeto, ou quando não existir mais reserva gerencial disponível (exceder o limite da dispensa), deverá ser acionado o patrocinador. VI - Administração do plano de gerenciamento de custos 1. Responsável pelo plano • Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento de tempo. • Rodrigo Xavier, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento de tempo. 2. Freqüência de atualização do plano de gerenciamento de custos O plano de gerenciamento de custos será reavaliado mensalmente na reunião mensal da equipe com o patrocinador, juntamente com os outros planos de gerenciamento do projeto. VII - Outros assuntos relacionados ao gerenciamento do custos do projeto não previstos neste plano Todas as solicitações não previstas neste plano deverão ser submetidas a reunião semanal da equipe de projetos para aprovação. Imediatamente após sua aprovação, deverão ser submetidas ao patrocinador para autorização, atualizando o plano de gerenciamento de escopo com o devido registro das alterações a serem efetivadas. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA 27/08/2013 Ricardo Souza Lima Detalhamento do orçamento aproximado 30/08/2013 Rodrigo Xavier F. de Oliveira Especificações de software e hardware 02/09/2013 Rodrigo Xavier F. de Oliveira Atualização dos términos das entregas APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 159 DECOMPOSIÇÃO DO ORÇAMENTO POR ATIVIDADE Nome do recurso Tipo Um Iniciais Grupo Unid. Taxa padrão Total TAS - Analista de Sistemas Trabalho TSI SUP 200% R$ 0,00 R$ 0,00 TAS - Analista de Suporte Trabalho TSU SUP 100% R$ 0,00 R$ 0,00 TAS - Analista de Desenvolvimento Trabalho TDS SUP 300% R$ 0,00 R$ 0,00 TAS - Administrador de BD Trabalho TBD SUP 100% R$ 0,00 R$ 0,00 ATS - Administrador de Redes Trabalho ARD TEC 200% R$ 0,00 R$ 0,00 ATS - Manutenção Trabalho AMN TEC 100% R$ 0,00 R$ 0,00 ATS - Assistente Administrativo Trabalho ASS MED 200% R$ 0,00 R$ 0,00 Impressora Laser Material ILS MAT 1 R$ 879,00 R$ 879,00 Computador 3.0+/4Gb+/750Gb+ Material COM MAT 6 R$ 2.300,00 R$ 13.800,00 Notebook 3.0+/4Gb+/500Gb+ Material NOT MAT 1 R$ 2.690,00 R$ 2.690,00 Servidor Material SER MAT 1 R$ 0,00 R$ 0,00 No-Break 1400VA Material NBK MAT 1 R$ 595,00 R$ 595,00 Monitor LED 20' Material MON MAT 6 R$ 550,00 R$ 3.300,00 Estabilizador 1000VA Material EST MAT 6 R$ 259,00 R$ 1.554,00 Access Point 150MBPS Material ACS MAT 1 R$ 182,00 R$ 182,00 Gerente de Projetos Trabalho GER PRO 100% R$ 0,00/hr R$ 0,00 Subcoordenador - Patrocinador Trabalho SUB PRO 100% R$ 0,00/hr R$ 0,00 Windows 7 Professional 64bits Material WIN MAT 1 R$ 0,00 R$ 0,00 MS Project 2010 Professional Material MSP MAT 1 R$ 0,00 R$ 0,00 Cabeamento Estruturado Material (m) CAB MAT 50 R$ 3,50 R$ 175,00 23.175,00R$ ORÇAMENTO POR RECURSOS DESCONSIDERANDO FOLHA SALARIAL DOS SERVIDORES 161 FLUXO DE CAIXA 162 APENDICE J – PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS Plano de Gerenciamento de Recursos Humanos Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DE RECURSOS HUMANOS STAFF MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira – Gerente do Projeto 02/09/2013 I – Organograma do Projeto II - Diretório do time do projeto (Team directory) No NOME ÁREA EMAIL TELEFONE 1 Rodrigo Xavier F. de Oliveira Gerência Projeto rodrigooliveira@rn.gov.br (84) 88551091 2 George Borges de Carvalho Programação georgeicapui@yahoo.com.br (84) 91114034 3 Flavio Silveira Cabral Programação flaviosilveira@rn.gov.br (84) 94014410 4 Sergio Alexandre da Rocha Programação sergiorocha@rn.gov.br (84) 32211766 5 Augusto Análise de DB augustodba@rn.gov.br (84) 32322705 6 Denise Guerra Wingerter Análise de Sistemas denisewingerter@rn.gov.br (84) 91879855 7 Francisco Carlos de Lima Manutenção jadbaljah@yahoo.com.br (84) 87051357 8 Thiago Gondim Manutenção thiagogondim@rn.gov.br (84) 88012571 9 Douglas Alberto Souza Lima Análise de Suporte gouglas@gmail.com (84) 88984386 10 Fátima Honorato Compras fatimah@rn.gov.br (84) 32322607 11 Flávia Souza Viana Suporte Hospitalar flaviaviana@rn.gov.br (84) 87411231 12 Altamir Processual altamirsesap@rn.gov.br (84) 32322655 13 Dolores Beutemiller Redes e Segurança doloresbeutemiller@rn.gov.br (84) 99574433 14 Francisco Canindé Lira Redes e Segurança canlira@hotmail.com (84) 91669773 15 Ricardo Souza Lima Gerência Divisão ricardo.lima@rn.gov.br (84) 88947721 III – Matriz de Responsabilidades Ricardo Souza Lima Patrocinador Desenvolvimento 3 Membros George Borges de Carvalho Programador Flávio Silveira Cabral Programador Sérgio Alexandre da Rocha Programador Banco de Dados 1 Membro Augusto DB Admin Análise de Sistemas 1 Membro Denise Guerra Wingerter An. de Sistema Suporte 1 Membro Douglas Souza Lima An. Suporte Manutenção 2 Membros Francisco Carlos Manutenção Thiago Gondim Manutenção Administrativo 3 Membros Altamir Processos Fátima Honorato Aquisições Flávia Viana Hospitalar Redes e Segurança 2 Membros Francisco Canindé Infraestrutura Dolores Beutemiller Servidores Rodrigo Xavier F. de Oliveira Gerente de Projetos Plano de Gerenciamento de Recursos Humanos Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br No NOME ÁREA P M O /B as e d e D ad o s C ad as tr o /A d m in is tr aç ão R eg u la çã o E st ad u al R ec e p çã o /A p o io S A D T A m o x/ Fa rm ác ia /E st o q u e R o u p ar ia /H ig ie n iz aç ão Le it o s/ In te rn aç ão /A lt a P .E le tr ô n ic o /A .M é d ic o En fe rm ag em A m b u la to ri al /E m er gê n ci a P ro n to S o co rr o C en tr o C ir ú rg ic o N u tr iç ão /D ie té ti ca P .G .P 1 Rodrigo Xavier Gerência Projeto A S R S A R S A R S A R A S 2 George Borges Programação R R 3 Flavio Silveira Cabral Programação S A R S A R S A R S A R 4 Sergio Alexandre Programação S A S A R S A R S A R S A 5 Augusto Análise de DB A A 6 Denise Guerra Análise de Sistemas S A A A A A A A A A A A A 7 Francisco Carlos Manutenção A 8 Thiago Gondim Manutenção A 9 Douglas Alberto Análise de Suporte A R 10 Fátima Honorato Compras A 11 Flávia Souza Viana Suporte Hospitalar A A A A A A A A A A A A A 12 Altamir Processual A S 13 Dolores Beutemiller Redes e Segurança A A A A A A A S S S S S S S 14 Francisco Canindé Redes e Segurança A S S S S S S A A A A A A A 15 Ricardo Souza Lima Gerência Divisão A A IV - Novos recursos, re-alocação e substituição de membros do time O gerente de projeto deve se empenhar pessoalmente na permanência de todos os integrantes da equipe durante o projeto e por isso será o coordenador deste plano de recursos humanos. Pela natureza do vínculo empregatício dos membros da equipe a coordenação do gerente de projetos fica comprometida com relação à sua intervenção sobre os membros para uma suposta permanência em casos de exoneração. No caso de re-alocação ou exoneração de profissional integrante do projeto, caberá ao gerente de projeto, juntamente com o departamento de recursos humanos, a identificação do substituto em comum acordo com as diretrizes do projeto e as funções a serem exercidas, cabendo a palavra final ao patrocinador à critério da administração. Novos recursos solicitados para o time devem ser previamente autorizados pelo patrocinador e serão arcados integralmente pelas reservas gerenciais do projeto. V - Treinamento Não estão previstos treinamentos para a equipe de projeto além dos treinamentos descritos no seu escopo. Qualquer necessidade extraordinária de treinamento deve ser aprovada previamente pelo gerente de projeto e autorizada pelo patrocinador, tendo seus custos alocados nas reservas gerenciais. VI - Avaliação de resultados O resultado do trabalho da equipe será avaliado mensalmente pelo gerente de projeto em reunião individual com cada membro do time do projeto e em reuniões conjuntas com os gerentes dos respectivos integrantes do projeto, quando esses se reportarem a outras áreas da SUININ, tais como os profissionais de TI e de Compras. O gerente de projeto será avaliado também mensalmente pelo patrocinador do projeto da mesma forma como os membros do time são avaliados. Ao fim do projeto será realizada uma reunião de avaliação de cada um dos integrantes do projeto, quando a avaliação final compilada do profissional será tabulada e encaminhada para o Departamento de Recursos Humanos na pessoa do Coordenador Carlos Pinto para uma avaliação de performance profissional. Plano de Gerenciamento de Recursos Humanos Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br Essa avaliação final compilada será feita através de um modelo circular sob o qual todos serão avaliados tanto pelas chefias quanto pelos pares e subordinados. • O gerente de projeto se auto-avaliará, será avaliado pelo patrocinador e será avaliado, também, por todos os membros do time. • Cada membro do time se auto-avaliará, será avaliado pelo gerente de projeto e será avaliado por, pelo menos, outros três membros do time, escolhidos por sorteio. • Todos os resultados serão compilados em uma ficha única que mostrará a percepção de cada um dos envolvidos no processo de avaliação. • Recursos contratados externamente através de suprimentos não serão avaliados através desse processo (consultores, instrutores, etc.). • Todos os recursos serão avaliados pelo patrocinador e registrados na avaliação de desempenho estadual. VIII - Frequência de avaliação consolidada dos resultados do time Os resultados nas avaliações mensais do time devem ser compilados e apresentados na última reunião mensal da equipe do projeto, prevista no plano de gerenciamento das comunicações. IX - Alocação financeira para o gerenciamento de RH Todas as medidas de gerenciamento de recursos humanos do projeto que requererem gasto adicional deverão ser alocadas dentro das reservas gerenciais do projeto, na categoria Reservas de Serviços, desde que dentro da alçada do gerente de projeto e do patrocinador. Para medidas prioritárias ou urgentes que dizem respeito ao gerenciamento do time que estejam fora da alçada do gerente de projeto, ou quando não existir mais reserva gerencial disponível, deverá ser acionado o patrocinador, uma vez que o gerente de projeto não tem autonomia para decidir utilizar a reserva de contingência de riscos no gerenciamento do time. VII - Administração do plano de gerenciamento de tempo 1. Responsável pelo plano • Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento de RH. • Rodrigo Xavier, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento de RH. 2. Freqüência de atualização do plano de gerenciamento de RH O plano de gerenciamento de RH será reavaliado mensalmente na primeira reunião mensal da Equipe do Projeto, juntamente com os outros planos de gerenciamento do projeto. As necessidades de atualização do plano antes da primeira reunião da equipe do projeto deverão ser tratadas segundo os procedimentos descritos no item Outros assuntos não previstos neste plano. XI - Outros assuntos relacionados ao gerenciamento de RH do projeto não previstos neste plano Todas as solicitações não previstas neste plano deverão ser submetidas a reunião da equipe para aprovação. Imediatamente após sua aprovação, deverão ser atualizados o plano de gerenciamento de RH com o devido registro das alterações efetivadas. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA 27/08/2013 Ricardo Souza Lima Detalhamento do orçamento aproximado 30/08/2013 Rodrigo Xavier F. de Oliveira Especificações de software e hardware 02/09/2013 Rodrigo Xavier F. de Oliveira Atualização dos términos das entregas APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. Nome do recurso Tipo Um Iniciais Grupo Unid. Taxa padrão Taxa h. extra Custo/uso TAS - Analista de Sistemas Trabalho TSI SUP 200% R$ 1.892,70/mês R$ 0,00/hr R$ 0,00 TAS - Analista de Suporte Trabalho TSU SUP 100% R$ 1.892,70/mês R$ 0,00/hr R$ 0,00 TAS - Analista de Desenvolvimento Trabalho TDS SUP 300% R$ 1.892,70/mês R$ 0,00/hr R$ 0,00 TAS - Administrador de BD Trabalho TBD SUP 100% R$ 1.892,70/mês R$ 0,00/hr R$ 0,00 ATS - Administrador de Redes Trabalho ARD TEC 200% R$ 1.030,40/mês R$ 0,00/hr R$ 0,00 ATS - Manutenção Trabalho AMN TEC 100% R$ 1.030,40/mês R$ 0,00/hr R$ 0,00 ATS - Assistente Administrativo Trabalho ASS MED 200% R$ 1.030,40/mês R$ 0,00/hr R$ 0,00 Impressora Laser Material ILS MAT R$ 879,00 R$ 0,00 Computador 3.0+/4Gb+/750Gb+ Material COM MAT R$ 2.300,00 R$ 0,00 Notebook 3.0+/4Gb+/500Gb+ Material NOT MAT R$ 2.690,00 R$ 0,00 Servidor Material SER MAT R$ 0,00 R$ 0,00 No-Break 1400VA Material NBK MAT R$ 595,00 R$ 0,00 Monitor LED 20' Material MON MAT R$ 550,00 R$ 0,00 Estabilizador 1000VA Material EST MAT R$ 259,00 R$ 0,00 Access Point 150MBPS Material ACS MAT R$ 182,00 R$ 0,00 Gerente de Projetos Trabalho GER PRO 100% R$ 0,00 R$ 0,00/hr R$ 0,00 Subcoordenador - Patrocinador Trabalho SUB PRO 100% R$ 0,00 R$ 0,00/hr R$ 0,00 Windows 7 Professional 64bits Material WIN MAT R$ 0,00 R$ 0,00 MS Project 2010 Professional Material MSP MAT R$ 0,00 R$ 0,00 Cabeamento Estruturado Material (m) CAB MAT R$ 3,50 R$ 0,00 Nome do recurso Tipo Um Iniciais Grupo Unid. Taxa padrão Taxa h. extra Custo/uso TAS - Analista de Sistemas Trabalho TSI SUP 200% R$ 0,00 R$ 0,00/hr R$ 0,00 TAS - Analista de Suporte Trabalho TSU SUP 100% R$ 0,00 R$ 0,00/hr R$ 0,00 TAS - Analista de Desenvolvimento Trabalho TDS SUP 300% R$ 0,00 R$ 0,00/hr R$ 0,00 TAS - Administrador de BD Trabalho TBD SUP 100% R$ 0,00 R$ 0,00/hr R$ 0,00 ATS - Administrador de Redes Trabalho ARD TEC 200% R$ 0,00 R$ 0,00/hr R$ 0,00 ATS - Manutenção Trabalho AMN TEC 100% R$ 0,00 R$ 0,00/hr R$ 0,00 ATS - Assistente Administrativo Trabalho ASS MED 200% R$ 0,00 R$ 0,00/hr R$ 0,00 Impressora Laser Material ILS MAT R$ 879,00 R$ 0,00 Computador 3.0+/4Gb+/750Gb+ Material COM MAT R$ 2.300,00 R$ 0,00 Notebook 3.0+/4Gb+/500Gb+ Material NOT MAT R$ 2.690,00 R$ 0,00 Servidor Material SER MAT R$ 0,00 R$ 0,00 No-Break 1400VA Material NBK MAT R$ 595,00 R$ 0,00 Monitor LED 20' Material MON MAT R$ 550,00 R$ 0,00 Estabilizador 1000VA Material EST MAT R$ 259,00 R$ 0,00 Access Point 150MBPS Material ACS MAT R$ 182,00 R$ 0,00 Gerente de Projetos Trabalho GER PRO 100% R$ 0,00/hr R$ 0,00/hr R$ 0,00 Subcoordenador - Patrocinador Trabalho SUB PRO 100% R$ 0,00/hr R$ 0,00/hr R$ 0,00 Windows 7 Professional 64bits Material WIN MAT R$ 0,00 R$ 0,00 MS Project 2010 Professional Material MSP MAT R$ 0,00 R$ 0,00 Cabeamento Estruturado Material (m) CAB MAT R$ 3,50 R$ 0,00 LISTA DE RECURSOS DESCONSIDERANDO FOLHA SALARIAL DOS SERVIDORES LISTA DE RECURSOS INCLUINDO FOLHA SALARIAL DOS SERVIDORES 167 ATIVIDADES POR RECURSO (QUEM FAZ O QUÊ) 168 APÊNDICE K – Planilha de Resposta aos Riscos NATUREZA RISCO PROB GRAV RESPOSTA TIPO COM O TEMPO Cronograma Calendário Padrão adotado para o cronograma do projeto podendo trazer atrasos em feriados e pontos facultativos em que não haja avanço remoto. Média Média Desenvolver um calendário a parte, atípico demonstrando os prováveis feriados e pontos facultativos nos próximos 12 meses. Passiva Constante Cronograma Servidor não realizar avanço em atividades que requerem acesso remoto nos feriados e fins de semana como previsto. Baixa Baixa Retirar o servidor da lista de anistia do ponto eletrônico e calcular as horas trabalhadas através do equipamento neste mês. Passiva Agrava Cronograma Férias não registradas no cronograma do pojeto podendo causar coincidência em vários funcionários no mesmo mês. Alta Média Criar uma planilha com os prováveis meses de cada servidor baseado em dados históricos e entrevistas. Passiva Constante Cronograma Rio Grande do Norte sediar a copa do mundo de futebol, podendo causar grande delay na execução do projeto com excessivos feriados e pontos facultativos sem avanço remoto. Média Alta Retirar o servidor da lista de anistia do ponto eletrônico e calcular as horas trabalhadas através do equipamento neste mês. Passiva Constante Partes Interessadas Stakeholders negativos influentes terem acesso constante aos documentos do projeto podendo causar transtornos tanto à equipe quanto ao projeto para defesa de seus interesses. Média Baixa Manter os documentos do projeto sempre na Subcoordenadoria de Informática e Informação no poder do patrocinador do projeto, manter uma planilha de controle de acessos. Atenuação Constante Equipamentos e Infraestrutura Computadores apresentarem defeito gerando delay no andamento das atividades. Baixa Baixa Manter os servidores da manutenção avisados da prioridade incontestável do Escritório de Projetos com relação à peças e serviços. Atenuação Agrava Software e Desenvolvimento Desconhecimento da equipe com relação à ferramentas de gerenciamento de projetos e desenvolvimento de sistemas. Baixa Média Manter sempre o servidor suplente ativo praticando na ferramenta e cobrar atividades complementares. Atenuação Diminui Equipamentos e Infraestrutura Infraestrutura defeituosa podendo causar danos ao cronograma do projeto em caso de falha. Baixa Baixa Substituição imediata da infraestrutura. Transferência Agrava Recursos Humanos Exoneração de membros da equipe do projeto Média Alta Solicitar transferência de servidores cedidos à unidades hospitalares. Transferência Constante Treinamento e Implantação Indisponibilidade dos usuários para treinamento, causando baixo volume de participantes na turma e gerando necessidade de turmas adicionais. Alta Média Manter sempre um Analista de Sistemas suplente para estas necessidades e acionar o Suporte Hospitalar. Transferência Diminui 169 APENDICE L – PLANO DE GERENCIAMENTO DAS AQUISIÇÕES E CONTRATAÇÕES Plano de Gerenciamento das Aquisições Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DAS AQUISIÇÕES PROCUREMENT MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira – Gerente do Projeto 02/09/2013 I - Descrição dos processos de gerenciamento das aquisições  O processo de gerenciamento das aquisições levará em conta que a forma de contratação e aquisição inicial de produtos e serviços será feita através de “processo carona”, uma vez que a SUININ não tem orçamento próprio e toda aquisição precisa ser feita à essa maneira.  Os “processos caronas” que integrarão os pedidos da SUININ serão coordenados pela Central Estadual de Regulação.  O gerente do projeto não terá autonomia sobre nenhum contrato ou medição de serviço previsto no orçamento, os quais ficarão à cargo da Central Estadual de Regulação.  Serão consideradas para o gerenciamento das aquisições apenas as aquisições diretamente relacionadas ao escopo do projeto. Inovações e novos recursos não serão abordados pelo gerenciamento das aquisições e serão passíveis de novas negociações.  Quaisquer solicitações de mudança no processo de aquisições ou nos objetos a serem adquiridos (previamente definidos) devem ser feitas por escrito ou através de e-mail, conforme descrito no plano de comunicações do projeto. II - Freqüência de avaliação dos processos de aquisições  Os processos de aquisições devem ser avaliados semanalmente e apresentados na reunião semanal, prevista no plano de gerenciamento das comunicações. III - Alocação financeira para o gerenciamento das aquisições  Qualquer necessidade de aquisição não prevista no orçamento e que requeira gasto adicional do projeto deve ser alocada dentro das reservas gerenciais do projeto, desde que dentro da alçada do gerente de projeto.  Para compras urgentes e prioritárias que estejam fora da alçada do gerente de projeto, ou quando não existe mais reserva gerencial disponível, deverá ser acionado o patrocinador, uma vez que o gerente de projeto não tem autonomia necessária para decidir utilizar a reserva de contingência de riscos para aquisições. IV - Administração do plano de gerenciamento das aquisições 1. Responsável pelo plano  Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento das aquisições, suas atualizações e relatórios.  Rodrigo Xavier F. de Oliveira, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento das aquisições. 2. Freqüência de atualização do plano de gerenciamento das aquisições  O plano de gerenciamento das aquisições será reavaliado mensalmente na primeira reunião mensal, juntamente com os outros planos de gerenciamento do projeto.  Necessidades de atualização do plano antes da primeira reunião mensal do projeto devem ser tratadas através dos procedimentos descritos no item Outros assuntos não previstos neste plano. Plano de Gerenciamento das Aquisições Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br V - Outros assuntos relacionados ao gerenciamento das aquisições do projeto não previstos neste plano  Todas as solicitações não previstas neste plano devem ser submetidas a reunião semanal para aprovação. Imediatamente após sua aprovação, deverão ser atualizados o plano de gerenciamento das aquisições com o devido registro das alterações efetivadas. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. Declaração de Trabalho Materiais e Equipamentos Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH DECLARAÇÃO DE TRABALHO MATERIAIS E EQUIPAMENTOS STATEMENT OF WORK Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira – Gerente do Projeto 02/09/2013 I - Propósito do documento Este documento tem como objetivo detalhar as necessidades de aquisição de materiais e equipamentos para o Projeto “SIGIH” – Sistema Integrado de Gestão da Informação Hospitalar. II - Especificação e quantitativos dos materiais e equipamentos a serem adquiridos Os materiais e equipamentos a serem adquiridos pelo projeto são os seguintes: Equipamentos de Informática (Hardware)  1 Servidor Xeon 3,2ghz com 6GB de Memória RAM, 4 HD’s espelhados com 500 GB (incluindo Backup) cada.  6 Microcomputadores Intel Dual Core 2GHz com 2Gb de Memória RAM, HD de 320 GB e rede. Equipamentos de Informática (Software)  6 licenças do Microsoft Project 2010 Professional com Microsoft Project Web Access para todas as máquinas  1 licença do Microsoft Project 2010 Server como servidor de projetos  SQL Server 2008 R2 como plataforma de banco de dados no servidor  1 licença Windows Server 2008 R2 Datacenter.  12 licenças Windows 7 Professional para componentes da equipe.  Todos os programas serão fornecidos gratuitamente pelo fabricante para fins de pesquisa e extensão. III - Condições de fornecimento Não há condições impostas pela SUININ para fornecimento dos materiais e equipamentos, as condições serão as expressas no processo de “carona” sendo desejado: • garantia mínima de 3 (três) anos para todos os equipamentos adquiridos; • suporte on-site para os servidores; IV - Qualificação dos proponentes O fornecedor contratado deverá atender às qualificações constantes no processo “carona”. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 173 APENDICE M – PLANO DE GERENCIAMENTO DAS COMUNICAÇÕES Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br PROJETO SIGIH PLANO DE GERENCIAMENTO DAS COMUNICAÇÕES COMMUNICATIONS MANAGEMENT PLAN Preparado por Douglas Alberto Sousa Lima – Gestor – Chefia Imediata Versão 1 Aprovado por Rodrigo Xavier F. de Oliveira – Gerente do Projeto 02/09/2013 I - Descrição dos processos de gerenciamento das comunicações • O gerenciamento das comunicações do projeto será realizado através dos processos de comunicação formal, estando incluído nessa categoria  e-mails,  publicações web (intranet-site),  memorandos internos,  documentos impressos,  reuniões. • Todas as reuniões semanais serão realizadas às sextas-feiras visando um interesse maior pelas correções de cada desenvolvedor aos fins de semana evitando gerar delay para o projeto. • Todas as informações do projeto devem ser atualizadas de modo constante no site do projeto, incluindo as atualizações diárias nos custos e nos prazos. • Todas as solicitações de mudança no processo de comunicação devem ser feitas por escrito ou através de e- mail e aprovadas pelo gerente do projeto. II - Eventos de comunicação O projeto terá os seguintes eventos de comunicação: 1. Kick Off Meeting  Objetivo – Dar a partida no projeto, apresentando as informações quanto ao seu objetivo e à sua importância para a SESAP/SUININ, aos seus prazos, aos seus custos, etc. Devem também ser apresentadas as principais entregas do projeto e os elementos de alto nível no WBS. Outro objetivo da reunião é motivar e dar suporte gerencial ao gerente de projeto e ao seu time, de modo a construir um ambiente colaborativo e integrado.  Metodologia – Apresentação do projeto, com utilização de computadores e planilhas.  Responsável - Rodrigo Xavier F. de Oliveira, gerente do projeto.  Envolvidos – Todos os envolvidos no time do projeto e patrocinador.  Data e Horário – Dia 02/09/2013 às 08:00.  Duração – 2 horas.  Local – Secretaria da SESAP/SUININ.  Outros – Lista de presença opcional. 2. Reunião de Acompanhamento  Objetivo – Avaliar todos os indicadores do projeto, incluindo os resultados parciais obtidos e a avaliação do cronograma, do orçamento, das reservas gerenciais e de contingência, dos riscos identificados, da qualidade obtida, do escopo funcional agregado e dos fornecimentos externos ao projeto. Tem como base garantir o cumprimento do plano do projeto, sendo o processo principal de aprovação das solicitações de mudança apresentadas no Sistema de controle integrado de mudanças.  Metodologia – Reunião com a utilização de projetor e computadores conectados ao sistema de informações do projeto.  Responsável – Rodrigo Xavier F. de Oliveira, gerente do projeto.  Envolvidos – Rodrigo Xavier F. de Oliveira, gerente do projeto, e toda a equipe de desenvolvimento.  Frequência – Semanal às sextas-feiras com início dia 02/09/2013 e término ao fim do projeto.  Reuniões extraordinárias – Podem ser solicitadas reuniões extraordinárias de CCB através de um pedido formal do gerente de projeto a partir do fluxo do sistema integrado de controle de mudanças do projeto.  Duração – 2 horas, com início às 09:00.  Local – Secretaria da SESAP/SUININ. Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br  Outros – Ata de reunião (com lista de presença) opcional. 3. Reunião de Intervenção  Objetivo – Reunião de Avaliação dos planos de projeto, com objetivo adicional de avaliar o desempenho do time do projeto, conforme previsto no plano de gerenciamento de RH, na categoria Avaliação de resultados. Irá deliberar a avaliação final da equipe, quando todos os resultados do desempenho individual de cada membro do time, incluindo o gerente de projetos, serão encaminhados para o departamento de recursos humanos.  Metodologia – Reuniões individuais entre os integrantes do time do projeto e o patrocinador para reportar acontecimentos e mudanças incluindo o preenchimento da avaliação de desempenho dos profissionais, conforme descrito no plano de RH.  Responsável – Rodrigo Xavier F. de Oliveira, gerente do projeto.  Envolvidos – Toda a equipe do projeto.  Freqüência – Mensal, no final de cada mês, com início a partir do dia 02/09/2013 e término ao final do projeto.  Duração – 2 horas, com início as 11:00 (imediatamente após a reunião de CCB).  Local – Secretaria da SESAP/SUININ.  Outros – Ata de reunião (com lista de presença) opcional. 4. Project Close out  Objetivo – Apresentar os resultados obtidos no projeto, bem como discutir as falhas e os problemas ocorridos de modo a fornecer base para o acúmulo de experiências sobre o projeto.  Metodologia – Apresentação dos resultados pelo gerente do projeto, bem como discussão direta através de mapas mentais sobre todos as questões e melhorias possíveis para futuros projetos.  Responsável – Rodrigo Xavier F. de Oliveira, gerente do projeto.  Envolvidos – Todos os envolvidos no time do projeto, patrocinador e convidados (executivos da empresa).  Toda data disponível ao fechamento de cada módulo, às 9h.  Duração – 4 horas.  Local – Secretaria da SESAP/SUININ.  Outros – Lista de presença opcional. III - Cronograma dos eventos de comunicação Cronograma de reuniões semanais para o projeto-piloto Cronograma de Reuniões mensais para todo o projeto Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br IV - Relatórios do projeto Os principais relatórios a serem publicados no sistema de informações do projeto são apresentados a seguir. Todos esses relatórios serão gerados diariamente pelos responsáveis e publicados no site do projeto. Qualquer outra necessidade de relatórios de progresso para as reuniões semanais previstas deverá ser solicitada com antecedência de 48 horas e por escrito com autorização do gerente de projetos. 1. WBS ou EAP (Estrutura Analítica do Projeto) A representação a seguir é o padrão para a visualização do WBS durante o progresso do projeto, onde as atividades concluídas são apresentadas em verde, as atividades em execução em amarelo e as não iniciadas em branco, incluindo também o percentual completo da atividade dentro da caixa da atividade. Responsável: Rodrigo Xavier F. de Oliveira Área: Gerenciamento de escopo Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br 2. Gráfico de Gantt O gráfico de Gantt do projeto será evidenciado através de barras no tempo para todas as atividades do projeto ao longo de sua execução. Responsável: Rodrigo Xavier F. de Oliveira Área: Gerenciamento de tempo Lista de Tarefas para o projeto-piloto “Modulo PMO e Base de Dados” Gráfico de Gantt para o Projeto-Piloto “Modulo PMO e Base de Dados” Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br Gráfico de Gantt com Entregas para todo o Projeto 5. Percentual completo Relatório que apresenta o percentual completo de cada uma das atividades previstas (de 0 a 100), identificando as atividades concluídas, as em andamento e as atividades a iniciar. A data apresentada no relatório é a data projetada para o término do projeto. Responsável: Rodrigo Xavier F. de Oliveira Área: Gerenciamento de tempo INCLUIR GRAFICO DE PERCENTUAL COMPLETO 6. Diagrama de marcos Relatório que apresenta as datas de conclusão de cada atividade com seus respectivos desvios, apresentando o atraso/adiantamento da atividade, bem como o status de cada atividade com relação ao tempo através de um indicador gráfico de status do projeto, onde o status pode indicar um adiantamento do trabalho, um adiantamento inferior a 5% do previsto e uma projeção de atraso no marco. Responsável: Rodrigo Xavier F. de Oliveira Área: Gerenciamento de tempo e escopo INCLUIR DIAGRAMA DE MARCOS V - Ambiente técnico e estrutura de armazenamento e distribuição da informação (EPM) A estrutura de armazenamento e distribuição da informação será realizada integralmente pela internet através do site pmo.saude.rn.gov.br. O ambiente de trabalho contará com um servidor destinado a suportar as características da organização, incluindo banco de dados consolidado de projetos, pool de recursos e arquivo de configuração corporativos, ferramentas de gerenciamento de relatórios dinâmicos (Análise de portfólio), bem como o gerenciamento de documentos do projeto. Plano de Gerenciamento das Comunicações Secretaria de Estado da Saúde Pública do Rio Grande do Norte - SUININ suinin@rn.gov.br Os usuários do ambiente utilizarão a intranet para atualizar e acessar informações do projeto, permitindo o planejamento de colaboração entre os integrantes do grupo de trabalho, os gerentes de projeto e outros envolvidos, facilitando a troca de informações sobre o projeto e o trabalho com elas em um site da Web. O ambiente também permitirá que os usuários exibam, atualizem e analisem informações sobre o projeto através de um navegador da Web, além de ajudar os integrantes da equipe a se comunicarem com seus gerentes sobre as tarefas que estão executando, fornecendo um local onde todos, inclusive os gerentes seniores, podem obter informações sobre o projeto. VI - Alocação financeira para o gerenciamento das comunicações Os custos relativos ao gerenciamento das comunicações serão considerados, para fins de projeto, como despesas administrativas e não serão incluídos nos custos do projeto, uma vez que o plano de gerenciamento de custos prevê a contabilização de apenas gastos adicionais ao projeto. No caso de necessidade de despesas no processo de comunicação, essas despesas podem ser alocadas dentro das reservas gerenciais do projeto, desde que dentro da alçada do gerente de projeto. Para necessidades prioritárias que estejam fora da alçada do gerente de projeto, ou quando não existe mais reserva gerencial disponível, deverá ser acionado o patrocinador, já que o gerente de projeto não tem autonomia necessária para decidir utilizar a reserva de contingência de riscos no gerenciamento das comunicações. VII - Administração do plano de gerenciamento das comunicações 1. Responsável pelo plano • Douglas Albert de Souza Lima, membro do time do projeto, será o responsável direto pelo plano de gerenciamento das comunicações. • Rodrigo Xavier F. de Oliveira, membro do time do projeto, será suplente do responsável direto pelo plano de gerenciamento das comunicações. 2. Freqüência de atualização do plano de gerenciamento das comunicações O plano de gerenciamento das comunicações será reavaliado mensalmente na primeira reunião mensal, juntamente com os outros planos de gerenciamento do projeto. As necessidades de atualização do plano antes da primeira reunião mensal do projeto deverão ser tratadas através dos procedimentos descritos no item Outros assuntos não previstos neste plano. VIII - Outros assuntos relacionados ao gerenciamento das comunicações do projeto não previstos neste plano Todas as solicitações não previstas neste plano devem ser submetidas a reunião semanal para aprovação. Imediatamente após sua aprovação devem ser atualizadas no plano de gerenciamento das comunicações com seu devido registro de alterações. REGISTRO DE ALTERAÇÕES DATA MODIFICADO POR DESCRIÇÃO DA MUDANÇA APROVAÇÕES Rodrigo Xavier F. de Oliveira Gerente do Projeto Data 02/09/2013 Nota: Quaisquer alterações neste documento deverão ser submetidas ao processo de controle de projeto no site http://pmo.saude.rn.gov.br para aprovações antes de serem incorporadas a este documento. Este documento segue à risca o modelo estabelecido por Ricardo Viana Vargas para o Plano de Gerenciamento de Projetos em seu projeto didático Novas Fronteiras. 182 ANEXO A – RELATÓRIO DE GESTÃO ANEXO A - RELATÓRIO DE GESTÃO - 2013 1- Inserção de todas as unidades hospitalares, administrativas e de referência situadas em Natal no programa GIGANATAL, onde a conectividade de internet/intranet será provida por um cinturão de fibra ótica já instalada (inicialmente contemplará as unidades do entorno do HMWG e HUOL) e posteriormente à ampliação deste cinturão (unidades no entorno dos IFRNs da zona norte), gerando aumento substancial de velocidade e grande economicidade, tendo em vista que não será preciso pagamento destes links; 2- Entrada de 02 (dois) novos analistas de sistemas, dos quais 01 (um) em regime de plantão; troca da chefia de grupo para entrada de servidor externo especialista em manutenção de microcomputadores, ampliando o quadro em mais 01 (um) servidor; 3- Troca da torre de tecnologia Wi-Max e alinhamento das antenas replicadoras de sinal de intranet/internet, situada no teto desta cede beneficiando as unidades dependentes desta tecnologia: SESAP, Centrais do Cidadão e Polícia Militar; 4- Ampliação da banda de internet/intranet contratadas com o consórcio Oi/Vectra, aumentando nossa velocidade de rede em 93,75% (de 16MB para 31MB) com o custo 22,89% maior (de R$ 91.459,33 para R$ 112.395,82), conseguido através de negociações com os consortes, reorganização e redistribuição da banda, troca de tecnologia de equipamentos obsoletos e retirada de links inativos/defeituosos; 5- Aditivo de 24,99% ao contrato de impressão offset realizado entre esta Secretaria e a empresa Maquip Ltda, representando o incremento de mais 20 (vinte) equipamentos de impressão/digitalização/fax em unidade hospitalares e administrativas que não tinham cobertura contratual, evitando assim o deslocamento de técnicos para municípios vizinhos ou ao nível central para realização de simples atividade de impressão/cópia de documentos, contribuindo para a melhoria, celeridade e economicidade do serviço; 6- Inserção na rede INFOVIA (intranet/internet) das seguintes unidades: Hosp. Dr. João Machado, Hosp. Dr. Ruy Pereira dos Santos, e Hosp. da Mulher em Mossoró; 7- Finalização da implantação do Sistema de Tratamento Fora do Domicílio, responsável pelo cadastro, acompanhamento e controle de forma digital e segura de todos os pacientes que buscam o serviço, desde a metade do segundo semestre deste ano; 8- Suporte na aquisição dos equipamentos de informática para compor a Central Metropolitana de Regulação, Núcleos Regionais e demais Centrais de Regulação em nosso Estado, sendo: 184 (cento e oitenta e quatro) microcomputadores completos (CPU, mouse, teclado e monitor; 08 (oito) notebooks; 236 (duzentos e trinta e seis) nobeaks; 56 (cinqüenta e seis) impressoras laser multifuncionais; 04 (quatro) impressoras laser multifuncionais; 60 (sessenta) estabilizadores; 42 (quarenta e dois) switches de rede; 03 (três) projetores multimídia; 10 (dez) pontos de acesso wireless; e 06 (seis) pen drives de 32GB; 9- Criação do Portal de Sistemas da SESAP (repositório de sistemas de informática criados ou incorporados ao domínio da Secretaria); projeto em andamento para a criação do Sistema e Demandas (responsável por concentrar as demandas urgentes a serem realizadas por determinação do Secretário de Saúde ou dos coordenadores sob sua supervisão, com possibilidade de acesso externo à rede da SESAP); e migração do portal de sites da saúde através de apoio da Coordenadoria de Tecnologia da Informação e Comunicação (COTIC/SEARH); 10- Revisão da rede lógica de diversas unidades hospitalares, possibilitando acesso aos sistemas de informática ligados a saúde, acesso à rede de internet/intranet, dentre eles: Hosp. Dr. João Machado, Hosp. Ruy Pereira dos Santos, Laboratório Central etc.; 11- Liquidação de débitos com o consórcio Oi/Vecra desde 2010, fator gerador de cortes dos links por falta de pagamento, interrompendo o bom andamento do serviço nas unidades afetadas. Atenciosamente, Ricardo de Souza Lima Subcoordenador/SUININ Mat.: 204.530-2