Projeto. GESTÃO PM News Ano 3 N 8 São Paulo Agosto-Dezembro de 2005

Transcrição

1 Projeto WBS s GESTÃO PM News Ano 3 N 8 São Paulo Agosto-Dezembro de 2005 Gerenciamento Editorial Prezados Colegas, é com grande prazer que publicamos a 8.a edição da Gestão PM News, a edição do segundo semestre de 2005 e já em clima de fim de ano, na qual contamos com os artigos: - Estruturas Organizacionais, Rede Informal e a Síndrome da Ovelha, que aborda os aspectos não técnicos do gerente de projetos, destacando a influência na organização. - Iniciando um Projeto - Análise de Requisitos para Sistemas de Informações, que aborda o grande desafio da gestão de requisitos, fator chave na estruturação do escopo em projetos de TI. - Por que eficiência em risco é um aspecto chave de melhores práticas de projetos, tratando da importância da gestão de riscos e da aplicação da dose certa de formalismo (relativização) e da complexidade das técnicas de acordo com o porte, complexidade e criticidade do projeto. Gestão PM News Ano 3 No /27

2 - Administrando seu Portfolio Individual de Projetos, que sintetiza alguns conceitos importantes sobre o tema (gerenciamento de portfolio e balanced scorecard) e propõe sua adaptação para outros níveis hierárquicos da organização. Saudações e um 2006 baseado no crescente profissionalismo do gerenciamento de projetos, podendo agregar cada vez mais valor aos negócios, resultando na melhoria da taxa de sucesso dos desafios corporativos! Augusto Camargos, PMP. Gestão PM News Ano 3 No /27

3 Índice Remissivo EDITORIAL... 1 ESTRUTURAS ORGANIZACIONAIS, REDE INFORMAL E A SÍNDROME DA OVELHA... 4 INTRODUÇÃO... 4 INFLUÊNCIA NA ORGANIZAÇÃO... 4 ESTRUTURAS ORGANIZACIONAIS... 4 REDE INFORMAL... 5 A SÍNDROME DA OVELHA... 6 CONCLUSÃO... 6 INICIANDO UM PROJETO - ANÁLISE DE REQUISITOS PARA SISTEMAS DE INFORMAÇÕES... 7 INTRODUÇÃO... 7 PROJETOS DE SOFTWARE RESULTADOS... 8 O QUE SERIA REQUISITOS DE SISTEMAS?... 9 ERROS NA FASE DE ANÁLISE DE REQUISITOS CONSEQÜÊNCIA DE ERROS NA FASE DE ANÁLISE DOS REQUISITOS DE SOFTWARE MÉTODOS DE ANÁLISE DE REQUISITOS ELABORAÇÃO DO PLANO DE AÇÃO INICIAL PARA O DESENVOLVIMENTO DA ANÁLISE DE REQUISITOS CONCLUSÃO POR QUE EFICIÊNCIA EM RISCO É UM ASPECTO CHAVE DE MELHORES PRÁTICAS DE PROJETOS APLICAÇÃO ADMINISTRANDO SEU PORTFOLIO INDIVIDUAL DE PROJETOS RESUMO INTRODUÇÃO CONCEITOS IMPORTANTES ADAPTAÇÕES NECESSÁRIAS CONSIDERAÇÕES FINAIS...26 Gestão PM News Ano 3 No /27

4 Estruturas Organizacionais, Rede Informal e a Síndrome da Ovelha Augusto Camargos, PMP. Introdução Ser técnico ou não ser técnico? Esta questão aplicada ao gerente de projetos é digna de muitos debates e explanações a fim de deixar claro o papel e a missão da função em questão. O próprio PMI reconhece que o gerente de projetos precisa ter conhecimentos dos regulamentos e normas da área de atuação (área de aplicação). Não devemos entretanto, confundir esta consistência exigida com a execução de atividades designadas à equipe do projeto. Influência na Organização O maior desafio normalmente do gerente de projetos são as questões nãotécnicas, ou seja, desafios que vão além das questões relacionadas às atividades específicas do projeto. Um dos grandes desafios do gerente de projetos é fazer as coisas acontecerem e para isso a Influência na Organização é uma habilidade que merece destaque e é o foco deste artigo. É esperado do gerente de projetos uma atuação holística que vai desde o alinhamento com a liderança organizacional, a alta administração, a negociação contínua com os principais stakeholders, a manutenção de uma comunicação eficiente e de acordo com o combinado, a tomada de decisão no tempo correto, a liderança e motivação da equipe, em suma fazer o projeto acontecer apesar de todos os imprevistos que provavelmente surgirão. Este é o papel do gerente de projetos: o de grande viabilizador, facilitador, negociador, comunicador, líder, seja na diretoria à qual está diretamente subordinado, seja por toda a organização na qual o projeto se insere. Estruturas Organizacionais Para entendermos melhor os desafios organizacionais, podemos dividir a organização nas suas estuturas formais e informais, o que consequentemente gera poderes e influências formais e informais. Gestão PM News Ano 3 No /27

5 Por estruturas formais deve-se compreender a estrutura organizacional da empresa, que vai desde o modelo funcional/departamental, o modelo matricial, o modelo projetizado e o modelo misto (mistura dos demais). É claro que a forma de fazer o projeto acontecer terá suas diferenças e peculiaridades nas diferentes estruturas organizacionais. Na estrutura funcional o a atuação do gerente de projetos (que muitas vezes não tem o cargo formal) é calcada pelo direcionamento dos gerentes funcionais, enquanto na estrutura projetizada ele têm amplos poderes para demandar e negociar. Na estrutura matricial o gerente de projetos responde pelo projeto e às vezes ao chefe geral dos gerentes de projeto, mas continua hierarquicamente ligado à um gerente funcional. É bom ressaltar que não existe uma estrutura ideal ou melhor, na verdade o desafio é tirar o melhor de cada estrutura em favor ao sucesso do projeto. Por estruturas informais podemos destacar as várias influências além dos cargos formais, que vão desde o conhecido poder das secretárias, colaboradores com experiência em determinado segmento e de uma forma generalizada na empresa destaca-se o poder e conseqüências geradas pela comunicação informal. Rede Informal A rede informal, grapevine ou rádio peão é uma realidade nas organizações e apesar de despertar diferentes sentimentos nos gerentes e executivos não pode ser simplesmente eliminada, portanto deve ser compreendida e analisada em cada empresa. Usualmente a rede informal é rápida, atua paralelamente à comunicação formal, agindo sobre esta e vice-versa. Ou seja, a rádio peão pode influenciar decisões da gerência assim como as decisões comunicadas pela gerência certamente movimentarão a rádio peão. Existem correntes que acreditam que a rede informal circula qualquer informação, mas segundo a pesquisa de Keith Davis se mostrou bem seletiva, circulando por onde realmente poderia gerar impacto. Segundo ainda Keith Davis a rede informal ocorre predominantemente dentro da empresa e não em encontros e relacionamentos fora do trabalho, fato que potencializa a ação e influência gerencial sobre esta. A rede informal é um fator que deve ser levado em conta pelo nível gerencial. Os gerentes por sua vez devem analisá-la em sua organização e tentar influenciá-la, ou seja, revertê-la em forças que agreguem aos desejos e estratégias formais da empresa. Gestão PM News Ano 3 No /27

6 A Síndrome da Ovelha Com todos os fatores formais e informais que permeiam a empresa, além é claro de fatores externos, o que não podemos como gerentes de projetos é cair na síndrome da ovelha, a miopia da ingenuidade técnica. Uso esta figura de linguagem para deixar claro que nem sempre a ovelha pastando nos campos ensolarados, tranqüila e segura pelo seu pastor, está livre de surpresas variadas; como por exemplo lobos e outros animais selvagens capazes de acabar com a suposta estabilidade do pobre ovelha, que apenas pastava de acordo com o que era esperado dela. Conclusão Portanto para que o gerente de projetos alcance o óbvio esperado dele, que é o sucesso do projeto, deve estar atento a todas influências formais, informais, internas e externas, para que só restem apenas as surpresas realmente inevitáveis de qualquer projeto um pouco mais complexo. Sobre o autor Antonio Augusto Camargos é formado em Computação pela UFSCar, pós-graduado em Marketing pela ESPM e Certificado no PMI (Project Management Institute) como PMP. Atua como Gerente de Projetos em TI na área financeira, como Palestrante, Instrutor do Curso Preparatório de Certificação PMP da Dinsmore Associates e Professor do Curso de Pós-Graduação em Gerenciamento de Projetos da FIAP (Faculdade de Informática e Administração Paulista). Referências Bibliográficas Project Management Institute ; PMBOK Guide Third Edition Argyris, Chris; Comunicação Eficaz na Empresa Como Melhorar o Fluxo de Informações para Tomar Decisões Corretas Harvard Business Review Book/ by Chris Argyris, Fernando Bartolomé, Carl R. Rogers e outros Gestão PM News Ano 3 No /27

7 Iniciando um Projeto - Análise de Requisitos para Sistemas de Informações Ruggero Ruggieri Introdução A Análise de Requisitos é a fase de levantamento do problema a ser resolvido. Nesta fase podemos identificar os limites e as reais necessidades do cliente para o sistema. Podemos nesta fase limitar a análise exclusivamente ao problema em estudo, e evitar os processos que estarão fora do problema. Na figura 1.1 é representado um exemplo do ciclo de vida para o desenvolvimento de um software. Neste ciclo podemos verificar que o papel da análise de requisitos é responsável pela identificação de tendências tecnológicas que se não forem identificados a tempo, podendo tornar a instalação de software deficiente, em alguns casos o projeto poderá ser recomeçado. Figura 1.1 Cliente Análise de Requisitos Análise de Requisitos Produção de Produção Software de Software Projeto de Software Projeto de Software Análise de Requisitos Identificação dos problemas dos clientes. Projeto de Software A partir dos requisitos, este processo é responsável pela idealização das soluções do projeto. Gestão PM News Ano 3 No /27

8 Produção de Software Nesta fase identificamos os processos pela implementação dos elementos (programas, manuais, implantação, treinamento, etc.). Projetos de Software Resultados Segundo Booch, 1986: devemos chamar atenção sobre o fato de que o desenvolvimento orientado para objetos é um método que atinge o ciclo de vida apenas parcialmente. Ele está focado sobre os estágios de projeto e implementação, no desenvolvimento de software...é imprescindível o acoplamento de métodos apropriados de requisitos e análise, ao desenvolvimento orientado para objetos. Segundo dados estatísticos do relatório KPMG, divulgado em (A) Desvios de Cronograma (B) Excederam o custo estimado (C) Inadequados às necessidades de Negócios O gráfico da figura 2.1 constata-se que as ferramentas de desenvolvimento de programas de software e técnicas de desenvolvimento software melhoraram muito nos últimos anos. Melhoras no prazo de entrega, melhorias no desenvolvimento, mas se ao longo do ciclo de desenvolvimento os requisitos estiverem distorcidos ou não forem adequadamente coletados, as distorções continuarão a acontecer. Figura 2.1 Custos 87 % (A) 56 % (B) 45 % (C) Ciclo de Vida de Projetos Gestão PM News Ano 3 No /27

9 O que seria requisitos de sistemas? Pela definição de Dean, 1994: é qualquer coisa que restringe o sistema. Segundo SPCI (Software Productivity Consortium Incl): os requisitos definem o problema. Eles lhe dizem o que o software deverá fazer. Os demais passos do processo tradicional de desenvolvimento de software criam solução. Segundo Breitman, 1998: A análise de requisitos de software é a disciplina usada para capturar correta e complementando os requisitos de software e expectativas dos usuários de software e as técnicas e disciplinas da análise de requisitos de software tem como objetivo a elicitação de requisitos do macrosistemas. É a identificação das necessidades dos usuários de informações e comunicação dessas necessidades aos processos de construção de software. Figura 3.1 Algo que se deseja ou precisa caracterizar um contrato padrão com usuário resolver um problema ou atingir um objetivo do usuário Análise de Requisitos Análise de Requisitos Análise do negócio descrição completa "o que" e "como" deverá ser feito Segundo Pressman, 2000, define qualidade de software como: conformidade a requisitos funcionais e de desempenho explicitamente declarados a padrões de desenvolvimento claramente documentados e a características implícitas que são esperados de todo software profissionalmente desenvolvidos. Erros na fase de Análise de Requisitos. A Análise de Requisitos é responsável pela identificação dos objetivos a serem atingidos pelo software. Os erros cometidos durante a fase de análise, levarão a produção do software inconsistente e o comprometimento do projeto. Gestão PM News Ano 3 No /27

10 Conseqüência de erros na fase de Análise dos Requisitos de software. A Análise dos Requisitos é responsável pela identificação dos objetivos do cliente. Os levantamentos dos requisitos mal formulados, mal definidos ou incompletos, levarão para a fase do projeto e no desenvolvimento do software. Conseqüentemente o projeto ficará comprometido na medida em que os requisitos não forem consistentes e seguros. Segundo a SPCI, os custos relativos para a eliminação dos mesmos problemas nas etapas do desenvolvimento do projeto de software elevarão os custos 4X maior para eliminação do erro na fase de testes e na fase de manutenção do software será 100X maior. Figura 5.1 Custos $ Manutenção Requisitos Testes Fases Segundo dados, Alan Daves, 1998: 56% de todos os erros encontrados nos software, são originados na fase de análise de requisitos e 75% desses erros são detectados somente depois das etapas de implementação e testes. As pesquisas da KPMG, os erros de requisitos são distribuídos da seguinte forma conforme figura 5.2. Figura 5.2 Gestão PM News Ano 3 No /27

11 Localização errada do requisitos 2% 5% ambiguidades 13% 49% devido a fatos incorretos omissões inconsistências 31% O Ministério da Ciência e Tecnologia (MCT), publicou em 1995 uma pesquisa informando que 47,4% das empresas desenvolvedoras de software no Brasil utilizavam as técnicas de Análise de Requisitos. Figura ,4% Utilizam Análise de Requisitos Não Utilizam Análise de Requisitos 52,6% Conclusão: Muitos erros de projetos são cometidos e não são detectado no início do projeto pela não utilização da técnica de Análise de Requisitos. Conseqüentemente, o custo do projeto poderá crescer exponencialmente com o tempo. Métodos de Análise de Requisitos Reunião inicial com o Cliente Nesta etapa inicial com o cliente, todos os participantes interessados ou envolvidos no projeto deverão esta presentes. Elaborar um documento visão sobre os assuntos que deverão ser abordados. Nesta fase, os usuários têm a Gestão PM News Ano 3 No /27

12 liberdade de apresentarem toda a sua causa, todos os seus problemas, toda as sua necessidades, enfim, têm a liberdade de falarem o que bem entenderem, sobre a questão relativa a seu trabalho e sobre como acreditam que um sistema de informação proposto possa, eventualmente, auxilia-los. Nesta fase, o entrevistador deverá ficar atento para as expressões que: o usuário utiliza e que possam transparecer que ele sente necessidade de informações; caracterizem problemas que ele vem sentindo; caracterizem objetivos de evolução da sua organização. Esses aspectos precisam ser anotados. O que caracteriza a possibilidade de um sistema de informações vir a ser útil é a presença de certas palavras, mas sentenças formuladas pelo usuário tais como: Verbo saber, uma expressão do tipo eu nunca sei... ou eu gostaria de saber.... Outra característica é a presença de sentenças como: eles me perguntaram... ou o chefe questiona sobre.... Essas sentenças são pistas de que alguma informação é necessária. Os verbos planejar e controlar em todas as suas variações possíveis (por exemplo nossa meta é..., os estoques estão fora de controle... ); o controle, como visto anteriormente, dá-se a partir da comparação dos dados resultantes do planejamento versus os que são coletados na execução dos processos, caracterizando, portanto, a necessidade de informações; Calcular, montar relatório, montar gráfico, registrar, consultar. Um aspecto importante é que o entrevistador não deve solicitar detalhes sobre qualquer informação que estiver sendo transmitida nessa fase do levantamento dos dados. Não se sabe ao certo os efeitos da interferência do analista nesta fase, mas nos casos em que isso ocorreu o cliente entrou em detalhes que em nada alteraram o resultado final da análise, a não ser o fato de que o processo de levantamento de dados tornou-se mais demorado. Além disso, desconfia-se que o desvio da atenção do cliente sobre detalhes fazem com que o analista perca a noção da sua linha central de pensamento, deixando de exprimir a completeza da natureza do problema como seria direcionado pelo profissional. O principal aspecto que gerou essa desconfiança foi o fato de surgirem elementos totalmente estranhos à questão que estava sendo Gestão PM News Ano 3 No /27

13 apresentada, caracterizando a falta de coesão em determinados momentos do raciocínio. Em hipótese nenhuma o entrevistador deverá ser estimulado, nessa fase, com recomendações de possíveis relatórios ou consultas que o analista presume que sejam importantes. A experiência indicou que o raciocínio dos clientes, sobre a possibilidade de alguma funcionalidade ser disponibilizada por recomendação do analista é de que se a funcionalidade não vier a ajudar provavelmente também não vai atrapalhar, portanto, o analista provavelmente vai aceitar a sugestão, independentemente da sua real necessidade em relação à sugestão dada. A experiência indicou, também, que essas recomendações podem não ser úteis, mas provavelmente tornará o projeto mais oneroso, mais lento ou demorado, quebra do cronograma do projeto. Para ser implementados e podem dificultar a operação do sistema, obrigando os usuários à alimentação de determinados conjuntos de dados que não serviam ao propósito inicial do cliente. Conclusão: Método pelo qual se chega a descoberta dos requisitos Causas de algumas reuniões ou requisitos não serem identificadas: o Excessos de reuniões; o Reuniões que consomem muito tempo sem tempo prédeterminados sem coordenação; o Reuniões ineficientes e improdutivas falta de preparação. Essencial para o sucesso de uma reunião Antes da reunião, o Gerente de Requisitos ou de Projetos, deverá enviar para os participantes, uma agenda informando o assunto, participantes, tempo de início e final, papéis (definir o coordenador), problemas e resultados esperados pelo assunto abordado e objetivo de cada participante. Enviar para os participantes o material ou pauta da reunião. Identificação de Sub-Sistemas (Particionamento) O Gerente de Projetos ou Gerente de Requisitos, deverá identificar nesta primeira fase das entrevistas os possíveis desmembramentos do projeto de software. Os problemas freqüentemente são grandes demais e muito complexos para serem compreendidos como um todo. O particionamento divide o problema em partes mais facilmente entendidas. Através das interfaces Gestão PM News Ano 3 No /27

14 estabelecidas entre as partes, a função global do software pode ser executada. Particionamento Horizontal: decomposição funcional do problema. Particionamento Vertical: expõem detalhes crescentes. Particionamento horizontal Particionamento Vertical REQUISITOS Elaboração do Plano de Ação Inicial para o desenvolvimento da Análise de Requisitos Após a 1ª reunião com o usuário, identificados os objetivos dos sistemas, a complexidade do desenvolvimento e a necessidade da criação de subgrupos para os levantamentos do sistema. O Gerente de Projetos ou Gerente de Requisitos deverá elaborar as técnicas de entrevistas e a metodologia de Requisitos para a elaboração do desenvolvimento do software. Conclusão Com a necessidade da complexa indústria de software, os projetos corporativos onde os serviços de adaptação do software às necessidades específicas de cada cliente, causando interferência no processo de análise. Segundo Kaneko, 1994 a indústria de serviços a variedades de requisitos dos diversos consumidores complica a padronização de cada tipo de serviço, que se deve proporcionar uma vez que os resultados desses serviços raras vezes agradam a todos e, que quando agradam a maioria, normalmente não proporcionam uma satisfação total. Segundo Gause, 1991, as pessoas assimilam particularmente o que lhes parece conhecido ou lhes interessa. A não utilização da Análise de requisitos, o desenvolvedor de software é levado a promover arranjos capazes de comprometer seriamente o desenvolvimento. Com uma política este planejamento de Gestão PM News Ano 3 No /27

15 qualidade de software e de requisitos os acordos entre as partes passam a ser mais claros. Sobre o Autor Ruggero Ruggieri é Gerente de Projetos da Unidade PRODESP da Secretaria de Estado dos Negócios da Fazenda. ruggero@fazenda.sp.gov.br Referências Bibliográficas Dissertação sobre Análise de Requisitos para Sistemas de Informações, utilizando as ferramentas da Qualidade de Processos de Software Claudiomir Selner, 1999; Artigo publicado na Revista BQ-Qualidade As armas na defesa do meio Ambiente Luiz Carlos de Martini Jr., 1999; Trabalho de Apresentação sobre Análise de Requisitos de Software e de Sistema Professora Luciana Romani; Ishikawa, 1993 Controle de Qualidade Total à maneira Japonesa, Rio de Janeiro, Editora Campos; Booch, 1997 Grady, James Rumbaugh e Ivar Jacobson The Unified Modeling Language For Object-Oriented Development, SEPCI Some Data on Software Development, Software Productivity Consortium Service Corporation, Herdnon, Virginia; Gerenciamento de Projetos Estabelecendo Diferenciais Competitivos 5ª Edição Ricardo Vargas; Juran, J.M. A Qualidade desde o Projeto, São Paulo, Editora Pioneira, 1992; Trabalho de dissertação, Ana Elizabete Souza de Carvalho, Helena Cristina Tavares, Joelson Brelaz Castro Centro de Informática da Universidade Federal de Pernambuco Uma estratégia para Implantação de uma Gerência de Requisitos Visando a Melhoria de Processos de Software ; Trabalho de dissertação, Claudia Hazam, Julio César Sampaio do Prado Leite Indicadores para a Gerência de Requisitos. Gestão PM News Ano 3 No /27

16 Por que eficiência em risco é um aspecto chave de melhores práticas de projetos Tércia Rocha Este artigo explica o que eficiência em risco significa, porque é aspecto chave de melhores praticas e por que não se deve distribuir riscos no uso das práticas comuns como publicam alguns autores. Explica também, como a eficiência em risco pode utilizarse das distribuições de probabilidades acumuladas (curvas-s) comparadas e por que proporciona uma base para análise e decisão dos negócios de uma companhia. Inicialmente, concordamos com Chris Chapman no que diz respeito à utilização de eficiência em risco como aspecto chave das melhores práticas em projetos. Entendemos que medir riscos utilizando ferramentas adequadas é importante para uma sólida base de argumentação para: processos formais de gerenciamento formal de projetos de risco construído para as necessidades corporativas; abraçar o gerenciamento de oportunidades assim como o de riscos; medir perigos e oportunidades para auxiliar a tomada de decisões; desenvolver uma cultura de arriscar mais eficiente; e arriscar mais para uma maior recompensa. Basicamente, as incertezas relevantes são importante para a gestão de risco e gerenciamento da qualidade de todos os projetos. O que importa é saber que partes do projeto serão consideradas e seu comportamento em relação às incertezas e aos objetivos estratégicos da companhia, gerenciando o escopo e seus requisitos, decidindo por processos apropriados, seus custos e retornos, medindo a performance e os riscos associados. Todos os envolvidos em fazer tais escolhas necessitam entender as implicações, conforme explicita Chris Chapman. Gestão PM News Ano 3 No /27

17 É importante observar a profundidade e alcance da frase acima, visto que sua simplicidade carrega conceitos abrangentes e de alta relevância quando tratamos de relativizar o formalismo necessário para atender às melhores práticas na gestão de risco do projeto e seu grau de aderência aos objetivos estratégicos da companhia. Para que a relativização do formalismo seja possível sem ferir os conceitos de melhores práticas é necessário e fundamental que o grau de maturidade da cultura corporativa para riscos seja adequada para a tomada de decisão eficaz e eficiente. A teoria do portfolio de Marcowizt, que apresenta a relação entre risco e retorno na composição de uma carteira de investimentos, é bastante elucidativa quando aplicada à análise de risco da companhia baseada em sua carteira de projetos. Essa analogia facilita a compreensão sobre a importância da análise de risco na composição da carteira de projetos da companhia e da eficiência em sua gestão. A teoria de tomada de decisão inclui escolhas de múltiplos estágios retratados por árvores de decisões e dependência estatística. Na prática, ambas estruturas (cursas S e teoria do portfolio) precisam ser integradas e conjugadas. Neste aspecto, é importante ressaltar a equivalência entre a gestão de risco na composição de um portfolio e a gestão de risco eficiente dos projetos da companhia e gerenciamento global. Os casos exemplarmente citados no artigo Why risk efficiency is a key aspect of best practice projects levam ao entendimento de que as escolhas de soluções de menor custo para projetos que tenham a probabilidade deocorrência de eventos não desejáveis (riscos negativos) não são, em sua maioria, as melhores opções. Soluções mais custosas poderão mitigar riscos e seus custos poderão ser diluídos ao longo dos prazos dos projetos. Uma equipe treinada para mitigar riscos de projetos inicialmente pode ser entendida como acréscimo de custos para os projetos e para a companhia, mas quando seus medidores retratam a eficiente e a eficaz utilização dos instrumentos de mitigação de riscos, os valores agregados aos projetos e conseqüentemente à companhia serão compreendidos como resultado positivo obtido com as melhores práticas da gestão de negócio e risco de projeto da companhia. Todas as opções definidas por pontos na curva de eficiência de risco minimizam o risco para um dado nível de custo esperado e/ou minimizam o custo esperado para um dado nível de risco. Elas são Pareto Ótimo, conhecidas também como a regra dos 20- Gestão PM News Ano 3 No /27

18 80: para cada 20% dos itens analisados tem-se 80% dos resultados, definindo uma fronteira eficiente. Não podemos fazer melhor em uma dimensão sem fazer pior em outra. A eficiência na gestão dos riscos e seus custos consistem na análise da combinação entre menores custos e riscos associados considerados aceitáveis para a companhia. Decidir baseado neste conceito, apoiado em ferramentas simples de análise permite otimizar e simplificar o nível operacional. Nem sempre a melhor ferramenta para auxilio na tomada de decisão é perfeita para todos os portes de projetos. É importante observar que projetos complexos e de grande impacto para os negócios da companhia devem ser analisados de forma criteriosa e neste caso cabendo inclusive uma maior formalidade no gerenciamento dos riscos do projeto e o impacto desses na gestão do risco global da companhia. Neste caso, a utilização de ferramentas mais complexas, onde seja possível medir a combinação de diversos fatores e relacioná-los para atingir o ponto ótimo entre custo e risco aceitável deve contemplar uma gama de variáveis suficiente (fator cubo) para atingir o melhor resultado, o que não é possível com as ferramentas citadas acima na medição de risco eficiente para projetos de porte e complexidade inferiores. Por outro lado, caso a companhia não tenha maturidade suficiente para conviver com alternativas de maior ou menor formalidade, graduadas pelo nível de complexidade dos projetos e seus impactos, os tomadores de decisão serão incapazes de discernir entre boa sorte e bom gerenciamento e má sorte e mau gerenciamento o que acarreta exposição de risco desnecessária e de conseqüências não previsíveis, ou arriscadas, para a companhia. O centro de tudo isso é o papel dos trade-offs entre atributos como custo, tempo e qualidade muitas vezes imprecisos, mas normalmente críticos. Se este entendimento é alcançado, o uso informal do conceito das melhores práticas de gerenciamento de risco de projeto pode ser adotado de uma maneira efetiva para projetos muito simples, numa escala mais ampla do que é adotado correntemente e entendido em termos de alcance mais amplo do que algumas linhas mestras sugerem. Gestão PM News Ano 3 No /27

19 Aplicação A maioria das empresas é bastante dependente de tecnologia, logo os exemplos mais comuns estão focados na área de Tecnologia da Informação (TI). Por ser crítica na gestão de projetos, a área de tecnologia das companhias utiliza metodologia de desenvolvimento de sistemas que adota o gerenciamento de riscos com base nos requisitos que atendem os objetivos estratégicos da companhia. Dentro desse processo, o maior grau de formalidade é usado nos projetos de manutenção da base tecnológica e nos aplicativos onde a segurança da informação é critica. Adota-se um grau de formalidade intermediário para sistemas onde o nível crítico não envolva segurança da informação ou acesso de usuários externos (clientes). Existe ainda a informalidade na gestão de requisitos para sistemas administrativos utilizados internamente pelo staff. Generalizadamente, nos casos de manutenção evolutiva também é utilizado um grau alto de formalismo e para os casos de emergência existem procedimentos formais para o tratamento específico de cada incidente. Existe também procedimento formal para tratamento de incidentes e sua mitigação ou contingência que poderá propiciar um ciclo de manutenções evolutivas. Conscientes do elevado grau de criticidade dos negócios da companhia e a necessidade de mitigação de riscos sem incorrer no erro excesso de cuidado, que em muitos casos traria baixa eficiência em atingir os objetivos estratégicos da companhia, desenvolvem modelos de gestão de risco onde a combinação da utilização de diferentes graus de formalidade atinge o ponto que podemos chamar de Pareto ótimo. Não é possível citar exemplos específicos visto que um dos pontos críticos que permeiam sistemas de informação são os critérios utilizados para a mitigação de riscos corporativos que consistem no sigilo de informações onde um dos itens para sua mitigação é a assinatura, pelo staff, de contrato de sigilo, que trata dos deveres, responsabilidades e penalidades aplicáveis, chegando estas ao limite das ações penais cabíveis. De qualquer forma, existem critérios claros de melhores práticas de gerenciamento de risco para projetos e para as companhias de acordo com as práticas usuais nas Gestão PM News Ano 3 No /27

20 companhias dependentes de tecnologia, adaptadas à necessidade de eficiência exigida pelo mercado que atuam. Este artigo foi escrito com base no trabalho Why risk efficiency is a key aspect of best practice projects escrito por Chris Chapman e publicado no International Journal of Project Management em 2004 e com participação de Sara Alves, engenheira. Sobre a Autora Tércia Rocha é economista, pós-graduada em Mercado de Capitais pela EPGE/FGV e em Gestão de Projetos pela POLI/USP. Referencias Bibliográficas: CMM Capability Maturity Model; Modelos para Gestão de Projetos, João Alberto Arantes do Amaral e Ricardo Sbragio; A Qualidade Desde o Projeto Os Novos Passos para o Planejamento da Qualidade em Produtos e Serviços, J. M. Juran Pioneira; Creating The Project Office A Menager s Guide to Leading Organizational Change, Randall L.Englund, Robert J. Graham; Paul C. Dinsmore; Transformando Estratégias Empresariais em Resultados através da Gerência por Projetos, Qualitymark. Gestão PM News Ano 3 No /27