Principais Tópicos:
- Projetos
- Riscos
- Gerenciamento de Riscos
- Projetos de TI
- Análises Contratuais
- Desvios de Premissas do PMBOK
O que é um projeto?
Um projeto é, basicamente, a elaboração e execução de um planejamento a partir da definição de um objetivo a ser alcançado. Ou seja, se o meu objetivo é construir uma casa, antes disso eu preciso de um planejamento de como ela será, de sua planta, para depois executar o que foi planejado, isto é, a construção da casa.
De acordo com o PMBOK, uma das publicações estabelecidas como padrão de guia de projetos pelo PMI (Project Management Institute), que por sua vez, é uma associação para profissionais de Gerenciamento de Projetos, projeto é: “um esforço empreendido para criar um produto, serviço ou resultado único” (PMBOK, 2014, p.3).
A fim de cumprir os requisitos e obter um resultado satisfatório, existe o gerenciamento de projetos, que é a prática de conhecimentos, habilidades e técnicas para traçar atividades e atingir as demandas do projeto. O gerenciamento de projetos é dividido em cinco etapas: início, planejamento, execução, monitoramento/controle e encerramento.
Ele é composto, ainda, por dez áreas de conhecimento, sendo que uma delas é o gerenciamento de riscos. Antes de abordarmos do que se trata este setor, é importante entendermos o significado do termo. Risco é: a possibilidade de não obter êxito em algum negócio devido a um evento incerto.
O que significa gerenciar riscos
Desta forma, gerenciar riscos significa identificar e avaliar todas as variáveis, sejam elas negativas ou positivas, que possam afetar o projeto e preparar para responder às mesmas com o objetivo de reduzir ou eliminar os impactos dos riscos.
Processos de gerenciamento de riscos
O PMBOK propõem cinco processos de gerenciamento de riscos: planejamento, identificação, análise quantitativa e qualitativa, planejamento de respostas aos riscos e controle.
5 Processos de gerenciamento de riscos:
1 - Planejar o gerenciamento dos riscos: esta é a primeira fase e podemos dizer que uma das mais importantes em todo o processo, pois é neste momento que será definido como serão as atividades para gerenciar os riscos.
2 - Identificar os riscos: nesta etapa serão pontuados quais as possíveis variáveis que podem afetar o projeto de forma estruturada e organizada.
3 - Realizar análise quantitativa e qualitativa:
· Qualitativa: análise para hierarquizar os riscos a partir da probabilidade de ocorrência de cada.
· Quantitativa: esta avaliação tem por objetivo entender qual o impacto dos riscos no objetivo do projeto. Por exemplo: quanto a mais ele pode custar e quanto tempo a mais pode ser gasto para finalizar o projeto a partir do impacto de um evento incerto.
4 - Planejar as respostas aos riscos: neste momento são estabelecidas ações para minimizar os impactos dos riscos.
5 - Controlar: a última etapa objetiva monitorar constantemente os riscos. Em suma, repetir todo os processos anteriores para maximizar a probabilidade de atingir todos os objetivos do projeto.
Gerenciamento de riscos em projetos de TI
Quais os motivos que geram desvios de custo, prazo e qualidade?
Podemos concluir, portanto, que o gerenciamento de riscos no processo de gerenciamento de projetos é uma etapa de suma importância, pois é através deste procedimento que podemos identificar, prever e agir em prol de atingir os objetivos do projeto e evitar desvios como: custo, prazo e qualidade. No entanto, quando tratamos de projetos de TI e mais especificamente de projetos de implantação de ERP, dificilmente encontramos um projeto que tenha atingido seu objetivo final e que não tenha tido os desvios supracitados durante a sua execução.
Dados do Chaos Report, do The Standish Group, apontam que 70% dos projetos apresentam desvios de prazo, custo e qualidade. Fica, então, a pergunta: Se existe um manual para orientar a execução de projetos, com passos específicos para avaliar os riscos que podem afetá-lo, com o exato objetivo de evitar que o projeto não dê certo, por que o percentual mostra o contrário? Um dos grandes problemas é o contrato estabelecido entre cliente e fornecedor.
Na maioria dos casos, para não dizer em todos, o contrato não é claro em relação a diversos pontos como:
se o escopo do projeto será aberto ou fechado;
qual das partes arcará com eventuais desvios de custo;
entre outros pontos que não esclarecem como se dará a execução do projeto.
Sendo assim, fica claro que somente o processo de gerenciamento de riscos não é suficiente para garantir a conclusão com sucesso de um projeto de TI. É necessário, então, contar com uma auditoria especializada que avalie o contrato e o projeto, eliminando brechas que possam afetar o resultado.
Outro fator que evidencia a necessidade de uma auditoria de contratos quando falamos em projetos de TI, é o fato do cliente normalmente não possuir conhecimento suficiente sobre o objeto que está sendo vendido, o que aumenta as chances do projeto não atingir o resultado esperado, pois, o fornecedor pode omitir detalhes técnicos que somente ele possui, informações relevantes acerca do contrato, bem como formato de negócios que desamparam e deixam sem visibilidade aquele que adquire sistemas, podendo até criar situações em que o cliente necessite desembolsar mais do que o esperado para receber o projeto.
Percebemos, então, a importância em buscar uma assessoria especializada (quem está adquirindo software), para ir além das questões puramente técnicas, relacionando áreas distintas de conhecimento. Tais áreas necessárias à gestão de riscos são: auditoria do contrato, auditoria de projeto e auditoria de negócios (regimes de licenciamentos – métricas de precificação – metodologia de implantação – regimes de escopo), todas elas com o intuito de garantir ao adquirente de software não tenha que arcar com despesas que fugiram do orçamento, lidar com o fato de receber fora do prazo uma aquisição que custou caro ou, ainda, receber, mas não ficar satisfeito porque o projeto não cumpriu com os requesitos de qualidade que fora prometido.
As inúmeras promessas destes fornecedores, muitas vezes sem conhecer e levantar as necessidades do cliente adquirente de sistema são, portanto, um dos maiores fatores de insucesso de projetos de software, pois na maioria dos casos o adquirente compra o que precisa e o fornecedor vende o que tem, ensejando, assim, grandes rupturas e inúmeras dificuldades de alinhamentos entre as partes.
Por fim, cabe demonstrar que mitigar estes riscos é realizar entendimentos pré-venda e não pós-venda como é feito pela grande maioria dos fornecedores de sistemas nacionais e mundiais, relacionando contratualmente sobre responsabilidades e eventuais desvios, evitando, assim, que projetos sejam implantados sem a realização de levantamentos. Caso os fornecedores persistam na errônea ideia de não realizar o levantamento e consequentemente não precificar corretamente, estes que arquem contratualmente com as responsabilidades pelos eventuais desvios de escopo.
Equipe Cruvinel & Ortiz – Assessoria Especializada.
Redação: Verônica Jellifes
Supervisão:
Sr. Sthefano Scalon Cruvinel - CEO - Founder
Sr. Pedro H. M. T. Ortiz - Diretor Unidade Uberândia