Francielli da Silva Ferreira; Felipe Miranda de Souza Almeida

DOI: 10.22167/2675-6528-202600808

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

Analisou-se o gerenciamento de riscos em um projeto de implementação de soluções de Identity and Access Management (IAM) conduzido por uma empresa do setor de cibersegurança com atuação no Brasil. O estudo buscou compreender como os riscos foram tratados na prática e em que medida esse processo se aproximou ou se afastou das diretrizes propostas pelo Project Management Institute (PMI), além de propor recomendações aplicáveis a iniciativas futuras de natureza semelhante. A pesquisa caracterizou-se como aplicada, descritiva e de abordagem qualitativa, sendo desenvolvida por meio da análise documental, observação participante e realização de entrevistas com membros-chave da equipe do projeto. O projeto analisado envolveu a implantação de uma solução de governança de identidades e acessos, contemplando funcionalidades como gerenciamento do ciclo de vida e autenticação multifator. Os resultados evidenciaram que o gerenciamento de riscos ocorreu de forma predominantemente reativa, ainda que práticas como identificação, análise e definição de respostas tenham sido realizadas de maneira informal ao longo do projeto. Verificou-se a ausência de processos estruturados para análise qualitativa ou quantitativa e para o monitoramento contínuo dos riscos, em desacordo com as diretrizes do Project Management Body of Knowledge (PMBOK). Apesar disso, riscos relevantes foram identificados e tratados durante as principais fases do projeto. Concluiu-se que a adoção de práticas mais estruturadas de gerenciamento de riscos pôde contribuir para maior previsibilidade, melhor integração entre equipes e redução de impactos em projetos de implementação de soluções de IAM.

Palavras-chave: Cibersegurança; Gerenciamento de projetos; IAM; PMBOK.

1. Introdução

Em um cenário organizacional marcado pela crescente digitalização e pela interconexão de sistemas, a gestão de identidades digitais emergiu como um pilar estratégico para a segurança da informação e a continuidade dos negócios. Essa criticidade é reconhecida e normatizada por padrões globais de segurança, como os estabelecidos pela International Organization for Standardization (ISO, 2022) e pelo National Institute of Standards and Technology (NIST, 2017), que fornecem diretrizes essenciais para a proteção de ativos digitais.

A complexidade desse gerenciamento é amplificada pela adoção de ambientes em nuvem, pela necessidade de integração entre plataformas diversas e pela constante evolução das ameaças cibernéticas. Nesse contexto, falhas nos processos de gestão de acessos e identidades podem representar vetores significativos para incidentes de segurança, reforçando a demanda por controles mais estruturados e continuamente monitorados (NIST, 2017; ISO, 2022). A ausência de uma governança eficaz pode expor as organizações a riscos operacionais, financeiros e de reputação.

Nesse contexto, o gerenciamento de riscos assume uma função indispensável para o êxito de projetos, permitindo a identificação proativa, a análise e o tratamento de potenciais eventos que podem comprometer prazos, custos, escopo e a qualidade das entregas. Conforme as diretrizes do “Project Management Institute” (PMI, 2017), o gerenciamento de riscos deve ser conduzido de forma estruturada, contínua e integrada ao ciclo de vida do projeto. Em projetos de tecnologia da informação, especialmente aqueles relacionados à cibersegurança e controle de acessos, essa necessidade se torna ainda mais evidente, dado o alto nível de incerteza, a dependência de múltiplos sistemas e a constante evolução dos requisitos (Sommerville, 2011).

Contudo, a realidade prática em muitas organizações de tecnologia revela uma lacuna entre as práticas recomendadas e a execução. Rabechini Jr. e Carvalho (2013) observam que o gerenciamento de riscos frequentemente ocorre de maneira reativa, com foco na resolução de problemas à medida que surgem, em detrimento de abordagens preventivas e sistematizadas. Essa postura reativa está associada a níveis mais baixos de maturidade em gestão de projetos, resultando em maior variabilidade nos resultados e menor previsibilidade (Kerzner, 2017). A falta de padronização pode levar a retrabalho e desvios significativos, impactando a eficiência e a qualidade dos projetos.

A relevância de adotar práticas mais robustas em projetos de alta complexidade tecnológica é enfatizada por Keeling (2009). Projetos de “Identity and Access Management” (IAM) são particularmente complexos, envolvendo integração com sistemas legados, tratamento de dados sensíveis e interação entre diversas áreas organizacionais. Além disso, esses projetos enfrentam riscos específicos relacionados à governança de identidades, à qualidade dos dados e à própria estrutura organizacional, exigindo uma abordagem mais estruturada para sua condução (AlGhamdi; Win, 2013). A falha em gerenciar esses riscos de forma eficaz pode resultar em atrasos, custos adicionais e comprometimento da segurança.

Diante desse cenário, o presente estudo analisou o gerenciamento de riscos em um projeto real de implementação de soluções de IAM, conduzido por uma empresa norte-americana do setor de cibersegurança com forte atuação nacional, com o objetivo de compreender como os riscos foram tratados na prática e em que medida esse processo se aproximou ou se afastou das diretrizes propostas pelo PMI (2017), além de propor recomendações aplicáveis a iniciativas futuras de natureza semelhante.

2. Material e Métodos

O presente estudo caracterizou-se como uma pesquisa de natureza aplicada, descritiva e de abordagem qualitativa. A natureza aplicada buscou a utilização prática do conhecimento para solucionar problemas do cotidiano profissional (Bigaton et al., 2024). A abordagem descritiva e qualitativa visou descrever e compreender fenômenos por meio da análise interpretativa de dados não numéricos (Gil, 2008; Sampieri et al., 2013).

A pesquisa foi desenvolvida em uma provedora de soluções de Gerenciamento de Identidade e Acesso (IAM), empresa de médio porte do segmento de cibersegurança com atuação no Brasil. O objeto empírico foi um projeto de implementação de soluções de IAM, abrangendo 1.500 identidades gerenciadas e a integração de dez sistemas. O portfólio da empresa inclui plataforma para governança de identidades, autenticação e controle de acessos.

O projeto analisado consistiu na implementação de soluções de Governança de Identidades (IGA) e Gerenciamento de Acessos (AM). A IGA focou no gerenciamento empresarial de identidades e ciclo de vida do usuário, suportando SaaS ou IaaS. A AM destinou-se à gestão de acessos para Single Sign-On (SSO) e autenticação multifator, conforme edital público.

Para alcançar o objetivo proposto, o estudo foi desenvolvido em duas etapas. Na primeira, realizou-se uma análise do gerenciamento de riscos no projeto, buscando identificar as práticas e processos utilizados. A coleta de dados incluiu análise documental (atas de reunião, planos, relatórios, guias, especificações e gravações de reuniões) e observação participante da autora, que atuou como líder da implantação.

Complementarmente, buscaram-se as percepções dos membros-chave da equipe por meio de entrevistas. As perguntas encontram-se listadas no Apêndice A do TCC original. As entrevistas foram conduzidas com o diretor de pesquisa e desenvolvimento e o engenheiro de software principal da empresa, em ambiente virtual de reunião e registradas por gravação. O kick-off do projeto ocorreu em outubro de 2023.

Na segunda etapa do estudo, procedeu-se à análise qualitativa da gestão de riscos adotada no projeto. O objetivo foi identificar a aplicação de práticas de identificação e mitigação de riscos que se afastavam das diretrizes tradicionais estabelecidas pelo guia PMBOK (PMI, 2017). Os dados coletados permitiram a comparação entre a prática observada e as diretrizes metodológicas.

O processo de condução de projetos da empresa provedora estava estruturado em fases sequenciais: kick-off, especificação, desenvolvimento, testes e go-live. Durante a especificação, realizaram-se reuniões semanais para levantar requisitos e definir regras de negócio, identificando os “pontos de alerta” (riscos do projeto).

Os riscos identificados eram registrados em atas de reunião ou e-mails. Quando demandavam atuação da equipe de desenvolvimento, eram convertidos em cartões na ferramenta Jira para rastreamento das atividades. Não se utilizou classificação formal de riscos (baixo, médio ou alto) nem técnicas quantitativas como simulação de Monte Carlo.

A análise dos riscos ocorreu de forma conjunta com o cliente e, posteriormente, em discussões internas da equipe de desenvolvimento. A avaliação foi realizada empiricamente, considerando os impactos no cronograma e a complexidade técnica. As decisões sobre as ações de resposta aos riscos eram tomadas internamente ou em conjunto com o cliente, dependendo da origem do risco.

Na fase de testes, a equipe de desenvolvimento implementou as respostas aos riscos, realizando testes internos e conjuntos com o cliente para validação das integrações. Riscos residuais foram detectados e ajustados imediatamente. Após a aprovação do cliente, o documento de especificação foi atualizado. O monitoramento pós-implantação ocorreu via chamadas ad hoc, com encerramento reativo de riscos remanescentes.

3. Resultados e Discussão

A análise do projeto de implementação de soluções de Identity and Access Management (IAM) revelou que o gerenciamento de riscos foi conduzido de maneira predominantemente reativa. Embora não houvesse uma estrutura formalmente definida para as etapas de identificação, análise, planejamento de respostas e monitoramento, observou-se que elementos cruciais desse processo foram executados de forma informal ao longo de todo o ciclo de vida do projeto. Essa abordagem, embora tenha permitido a resolução de problemas emergentes, distanciou-se das práticas proativas e sistematizadas recomendadas para a gestão de projetos complexos, como os de cibersegurança, que exigem maior previsibilidade e controle sobre as incertezas.

A identificação dos riscos ocorreu majoritariamente durante as reuniões remotas de especificação do projeto, nas quais o cliente detalhava o cenário atual de seus sistemas e processos, denominado “AS IS”, e o cenário futuro desejado, “TO BE”. Nesse processo, o próprio cliente expressou preocupações sobre possíveis inconsistências no ambiente, bem como sobre integrações e regras pré-existentes que não poderiam ser afetadas. Adicionalmente, o diretor de desenvolvimento da provedora contribuiu, apontando limitações técnicas da arquitetura da solução IAM e necessidades para viabilizar os requisitos.

As discussões sobre os problemas identificados e as possíveis soluções foram realizadas em conjunto por ambas as partes, seja por meio de desenvolvimento de código, aprimoramentos na plataforma ou definição de novos procedimentos. A análise dos riscos, por sua vez, foi conduzida de forma empírica e colaborativa com o cliente, aprofundando-se em discussões internas entre o diretor de desenvolvimento e a equipe de desenvolvedores. Contudo, verificou-se a ausência de qualquer classificação formal dos riscos, como categorização por nível de impacto ou probabilidade.

A avaliação dos riscos priorizou os possíveis impactos no cronograma e a complexidade técnica das demandas. Nos casos em que se identificou um risco de atraso, buscou-se, em comum acordo com o cliente, simplificar as entregas, mesmo que parcialmente, para preservar os prazos estabelecidos. Os itens considerados riscos foram tratados em paralelo ao cronograma principal, visando evitar impactos nas datas acordadas, que eram sensíveis devido a negociações prévias com o cliente.

A definição das ações de resposta aos riscos variou conforme a origem do problema. Quando o risco estava associado ao ambiente ou aos sistemas do cliente, a equipe da provedora oferecia consultoria e apoio na análise, mas a decisão final cabia ao cliente. Por outro lado, riscos relacionados à própria solução da provedora eram gerenciados internamente, com decisões tomadas pelo diretor de desenvolvimento em conjunto com a equipe técnica, evidenciando um caráter predominantemente técnico nas resoluções e sua integração às atividades do projeto.

O registro dos riscos não seguia um padrão formal. Riscos que implicavam a criação ou alteração de regras de negócio, ou aqueles considerados críticos pelo cliente, eram documentados na especificação do projeto ou comunicados por e-mail. No entanto, itens considerados contornáveis nem sempre eram formalizados. Quando exigiam atuação da equipe de desenvolvimento, eram registrados como tarefas no Jira, permitindo o rastreamento, mas sem classificação formal de risco, como baixo, médio ou alto.

Os itens relacionados exclusivamente à plataforma da provedora não eram incluídos no documento de especificação, sendo registrados diretamente em cartões no Jira apenas quando demandavam intervenção técnica. A decisão sobre a criação desses registros era geralmente atribuída ao diretor de desenvolvimento. A construção do documento de especificação, por sua vez, ocorria de forma colaborativa, sem uma definição formal de responsabilidade, sendo elaborada principalmente pelos desenvolvedores envolvidos, especialmente aqueles responsáveis por atividades específicas ou pela condução técnica das implementações.

Adicionalmente, a empresa provedora seguia um processo próprio de condução de projetos, estruturado em fases sequenciais: kick-off, especificação, desenvolvimento, testes e go-live. Essa estrutura foi identificada com base na experiência prática da autora na gestão do projeto, onde atuou diretamente na coordenação dessas etapas, observando a aplicação dessas fases na prática da implantação da solução de IAM.

O kick-off do projeto consistiu em uma reunião remota de uma hora, realizada em outubro de 2023, marcando o início oficial da implantação da solução de IAM. O objetivo principal dessa reunião foi o alinhamento de expectativas entre o cliente e a equipe de implantação da provedora, a apresentação dos membros da equipe e o levantamento inicial de informações sobre os sistemas que seriam envolvidos no projeto, estabelecendo as bases para as fases subsequentes.

Durante a etapa de especificação, foram realizadas, em média, duas reuniões semanais, conforme verificado na agenda interna da empresa provedora. Nessas reuniões, discutiam-se as informações registradas em uma planilha preenchida pelo cliente, que servia como instrumento inicial para levantamento de requisitos e obtenção de detalhes adicionais sobre os sistemas a serem integrados. Os participantes incluíam o gestor de projetos, o diretor de desenvolvimento, o engenheiro de software da provedora, o analista de segurança do cliente e o responsável pelo sistema em discussão.

O objetivo principal dessas reuniões era compreender as formas de integração entre os sistemas do cliente e a solução de IAM da provedora, bem como levantar informações sobre o cenário atual de uso dos sistemas e definir, em conjunto com o cliente, as regras de negócio. Essas regras eram entendidas como o comportamento esperado dos sistemas após a integração com a solução de IAM. Ao longo dessa etapa, a maior parte dos riscos do projeto foi identificada, sendo denominados pela equipe como “pontos de alerta”.

Entre os principais pontos de alerta identificados nas reuniões de especificação, verificou-se que três dos dez sistemas indicados para integração eram legados, desenvolvidos internamente pela organização, e não havia profissionais com conhecimento técnico suficiente para apoiar o processo de integração. Outro risco relevante foi a limitação do ambiente de testes do setor de Recursos Humanos, cuja base de usuários possuía duração de apenas um dia, inviabilizando testes de longo prazo e impactando a validação de funcionalidades de ciclo de vida do usuário.

Adicionalmente, observou-se que as expectativas do cliente patrocinador do projeto, comunicadas inicialmente ao time de vendas da provedora, não foram devidamente alinhadas entre a equipe comercial e a equipe de implantação, gerando desalinhamentos iniciais. Por fim, identificou-se que a equipe do cliente designada para apoiar a implantação da solução não era a mesma responsável pelos sistemas a serem integrados, resultando em desconhecimento de processos e particularidades operacionais, o que dificultou o levantamento completo das informações necessárias para a integração.

Na fase de desenvolvimento, foram realizadas reuniões semanais exploratórias remotas com o cliente, e entrevistas com os responsáveis pelos sistemas geraram atas de reunião, gravações e atualizações no documento de especificação. Os riscos foram registrados em atas de reunião ou e-mails às partes interessadas, sem a criação de um documento específico de riscos. Identificaram-se riscos negativos como incompatibilidade de Interfaces de Programação de Aplicações (API) em sistemas legados devido à arquitetura desatualizada, resistência de usuários a novas regras de acesso por ausência de treinamento inicial, e atrasos em aprovações regulatórias devido à burocracia interna do cliente.

As respostas a esses riscos foram planejadas durante as reuniões, com a participação da consultora do cliente e da equipe de desenvolvimento da provedora, incluindo o diretor de pesquisa e desenvolvimento (P&D) e o engenheiro de software. Essas respostas foram incorporadas diretamente ao documento de especificação do projeto, garantindo que as ações fossem integradas ao plano de trabalho e executadas conforme as necessidades técnicas e operacionais identificadas.

Na etapa de testes, a equipe de desenvolvimento da provedora assumiu a implementação das respostas, desenvolvendo os recursos necessários e realizando testes internos e conjuntos com o cliente para validação das integrações. Durante os testes conjuntos, detectaram-se riscos residuais, como falhas pontuais em integrações, que resultaram em retrabalho localizado. Esses ajustes foram executados imediatamente pela equipe técnica, sem a aplicação de técnicas quantitativas de análise de risco, como a simulação de Monte Carlo.

Após a aprovação integral pelo cliente, o documento de especificação foi atualizado em sua versão final. Na fase de go-live, o projeto avançou para a entrada em produção após o aceite formal do cliente. O monitoramento dos riscos ocorreu por meio de chamadas ad hoc pós-implantação, com o encerramento reativo dos riscos remanescentes, sem a realização de auditorias periódicas ou o registro formal de lições aprendidas. Apesar dessas abordagens, o projeto foi concluído no prazo estipulado no cronograma final, com todas as especificações entregues, contrastando com o processo de Monitorar os Riscos preconizado pelo guia PMBOK.

Discussão dos resultados

Os achados deste estudo indicam que o gerenciamento de riscos no projeto analisado ocorreu de maneira predominantemente reativa, sem a presença de uma estrutura formalizada para identificação, análise e monitoramento contínuo dos riscos. Esse cenário corrobora os estudos em gestão de projetos, como os de Rabechini Jr. e Carvalho (2013), os quais apontam que, na prática, muitas equipes utilizam apenas o processo de identificação, negligenciando aspectos fundamentais como a avaliação, a organização das respostas e o monitoramento, o que pode comprometer a eficácia da gestão.

Embora a equipe tenha identificado diversos “pontos de alerta” ao longo da implantação, essas ocorrências foram tratadas de forma pontual, conforme surgiam nas reuniões com o cliente, o que limitou a previsibilidade e a capacidade de antecipação das respostas. Essa dinâmica se distancia da lógica recomendada pelo guia PMBOK (PMI, 2017), que estabelece que os riscos devem ser compreendidos e tratados de forma estruturada e iterativa ao longo de todo o ciclo de vida do projeto, com o objetivo de aumentar a probabilidade e o impacto dos riscos positivos e diminuir os riscos negativos.

A ausência de um registro específico de riscos também se mostrou uma característica limitante. De acordo com o PMI (2017), o Registro dos Riscos é o documento oficial essencial que captura os detalhes dos riscos individuais identificados, designa seus responsáveis e consolida a lista de respostas e ações de implementação. No caso estudado, as informações foram dispersas entre atas de reunião, e-mails e atualizações no documento de especificação, o que, embora contribua para a rastreabilidade imediata das decisões, não substitui um repositório formal de riscos com suas respectivas causas, impactos, responsáveis e respostas planejadas.

Em projetos complexos de IAM, a formalização defendida por esses padrões é crucial, pois concentra as informações para apoiar a análise e garantir que as respostas sejam implementadas de maneira inequívoca. Além disso, em projetos com múltiplas integrações e forte dependência de terceiros, como é o caso de soluções IAM, essa formalização tende a ser ainda mais importante, pois facilita o acompanhamento de riscos recorrentes, a priorização de ameaças e a comunicação entre os envolvidos, conforme apontado por Raz e Hillson (2005), que destacam a importância da gestão da informação em ambientes complexos.

Outro ponto importante diz respeito à própria natureza do projeto. A implantação de soluções de IAM envolve integração com sistemas legados, protocolos de federação, autenticação multifator, governança de identidades e múltiplas áreas usuárias, o que amplia sua complexidade técnica e organizacional. Nesse cenário, a identificação de riscos como incompatibilidade de APIs em sistemas antigos, indisponibilidade de especialistas nos sistemas legados e limitações nos ambientes de teste era esperada, pois a prática profissional em cibersegurança aponta justamente que sistemas legados costumam apresentar dificuldades de compatibilidade, limitações de visibilidade e maior exposição a falhas operacionais.

As fases de especificação e desenvolvimento concentraram a maior parte das incertezas do projeto, o que reforça a importância do levantamento detalhado de requisitos e da participação ativa dos responsáveis pelos sistemas do cliente. Quando a equipe que apoia a implantação não é a mesma que conhece os sistemas em profundidade, surgem lacunas de informação que podem comprometer o entendimento das regras de negócio e a definição de integrações adequadas. Esse achado evidencia que parte significativa do risco em projetos de IAM não está apenas na tecnologia em si, mas também na coordenação entre pessoas, áreas e informações, fator amplamente discutido por autores como Keeling (2009) como gargalo crítico para o desempenho global de projetos.

Ainda que o projeto tenha sido concluído dentro do prazo e com as entregas previstas, o resultado positivo não elimina a necessidade de aprimorar o processo com métodos estruturados para gerir os riscos. Pelo contrário, o desfecho satisfatório pode indicar que a equipe conseguiu responder aos problemas de forma competente, porém sem o apoio de um método formal que reduzisse o retrabalho, aumentasse a previsibilidade e favorecesse a aprendizagem organizacional. O PMI (2017) ressalta que o processo de realizar a análise qualitativa dos riscos é vital para priorizar ameaças e oportunidades, avaliando sistematicamente a probabilidade de ocorrência e o impacto nos objetivos do projeto, enquanto a análise quantitativa amplia a compreensão dos efeitos sobre o cronograma e os custos, especialmente em iniciativas complexas.

Conforme sugerem Raz e Hillson (2005), o uso de escalas e a construção de uma matriz de risco tornam a avaliação mais objetiva e evitam decisões baseadas apenas em percepções empíricas, fornecendo à equipe subsídios numéricos relevantes para a tomada de decisão e alocação de esforços. A ausência dessas ferramentas no projeto analisado representou uma lacuna na formalização do processo de gerenciamento de riscos, limitando a capacidade de uma análise mais profunda e sistemática dos eventos potenciais.

Também se observa que a etapa de monitoramento foi conduzida de forma limitada, com contatos conforme a necessidade após a implantação e sem registro formal de lições aprendidas. Isso reduz a capacidade da organização de transformar a experiência do projeto em conhecimento acumulado para iniciativas futuras. O PMI (2017) adverte que, em qualquer setor, a ausência de um repositório de lições aprendidas impede o amadurecimento organizacional. Em ambientes de cibersegurança e IAM, nos quais mudanças regulatórias, integrações técnicas e dependências externas são frequentes, a ausência desse aprendizado tende a reproduzir os mesmos gargalos em novos projetos, impactando a eficiência e a qualidade de futuras implementações.

Diante desse cenário, foi constatado que a ausência de padronização e de um processo estruturado de gerenciamento de riscos limitou não apenas a previsibilidade do projeto, mas também a capacidade de aprendizagem organizacional. Nesse contexto, a adoção de práticas sistematizadas, conforme proposta pelo PMI (2017), representou uma oportunidade relevante de melhoria, especialmente no que diz respeito à formalização da identificação, da análise, do registro e do monitoramento dos riscos ao longo do ciclo de vida do projeto, contribuindo para a maturidade da gestão.

Por fim, fica evidente que a etapa de monitoramento ocorreu de forma pontual. O PMI (2017) prescreve que os riscos devem ser continuamente reavaliados e que as lições aprendidas desempenham um papel central no gerenciamento do conhecimento. O documento destaca ainda que o Registro das Lições Aprendidas deve ser criado no início do projeto e atualizado para evitar a repetição de erros, sendo transferido para um repositório organizacional ao final de cada fase ou do próprio projeto. Em ambientes de cibersegurança e IAM, a inobservância dessa prática impede a transformação da experiência tática em conhecimento consolidado e tende a reproduzir os mesmos gargalos técnicos em novas implementações, comprometendo a melhoria contínua.

Proposta de melhoria

Considerando os processos e lacunas identificados e fundamentado nas boas práticas do guia PMBOK (PMI, 2017), propõe-se a implantação de um framework estruturado para a gestão de riscos nos projetos de implementação de IAM da empresa. A presente proposta busca promover a transição de um modelo reativo para um processo contínuo e preventivo, estruturado nas seguintes etapas metodológicas, visando maior previsibilidade e eficiência na condução de projetos complexos de cibersegurança.

A primeira etapa, o planejamento do gerenciamento dos riscos, envolve a definição, antes do início da execução, de como as atividades de risco serão conduzidas. Isso inclui a criação de uma Estrutura Analítica dos Riscos (EAR) padronizada para implementações de IAM, contemplando categorias como falhas de integração, qualidade de dados legados do cliente e resistência cultural. Também se faz necessária a definição formal das escalas da Matriz de Probabilidade e Impacto. O gerente de projetos, em conjunto com o diretor de desenvolvimento e o patrocinador, deve aprovar a metodologia, definir os limites de tolerância a riscos e alocar recursos e tempo para essas atividades, garantindo um alinhamento estratégico.

Na etapa de identificação dos riscos, o objetivo é levantar sistematicamente as ameaças e oportunidades. Além das opiniões especializadas coletadas nas reuniões remotas de especificação do cenário atual (“AS-IS”) e futuro (“TO-BE”), a equipe deve incorporar o uso de listas de verificação (“checklists”) baseadas em lições aprendidas de projetos anteriores e sessões estruturadas de brainstorming. Todo risco identificado deve ser formalmente documentado em um Registro dos Riscos unificado. A responsabilidade por essa etapa recai sobre toda a equipe técnica envolvida, representantes do cliente (para apontar riscos de ambiente ou infraestrutura) e o gerente de projetos como facilitador, promovendo uma visão abrangente.

A análise qualitativa dos riscos busca superar a avaliação empírica atual, priorizando os riscos para ação imediata por meio da avaliação de sua probabilidade de ocorrência e impacto no cronograma, custo e qualidade da solução. Riscos técnicos e operacionais críticos devem ser categorizados na Matriz de Probabilidade e Impacto, permitindo que a equipe foque seus esforços nas ameaças mais severas. O gerente de projetos atua na condução da análise, com forte apoio técnico do diretor de desenvolvimento e/ou dos desenvolvedores para estimar com precisão o impacto das demandas técnicas, garantindo uma avaliação robusta.

O planejamento e implementação de respostas envolve o desenvolvimento de opções e estratégias formais, como prevenir, mitigar, transferir ou aceitar, para cada risco priorizado, evitando que itens complexos sejam tratados apenas como contornos informais no backlog. Após a definição, os planos de resposta devem ser integrados ao cronograma principal, convertidos em tarefas na ferramenta de acompanhamento de atividades e executados conforme planejado. Para cada risco documentado, deve ser explicitamente designado um “dono do risco”, responsável direto pela execução da resposta, que pode ser um desenvolvedor sênior ou até mesmo a equipe do cliente em casos de pendências pré-existentes.

Por fim, o monitoramento contínuo visa acompanhar a eficácia das respostas implementadas e identificar novos riscos iterativamente à medida que o desenvolvimento e as integrações avançam. Recomenda-se a inclusão de uma pauta rápida sobre o status dos riscos nas reuniões periódicas de acompanhamento, garantindo que o Registro dos Riscos seja um documento vivo e atualizado. O gerente de projetos é o responsável por monitorar o cenário geral, enquanto os “donos dos riscos” reportam o andamento das ações mitigadoras, e a equipe técnica como um todo é responsável por alimentar o repositório de lições aprendidas para mitigar falhas em projetos futuros, promovendo a melhoria contínua.

Para assegurar a efetividade da proposta de melhoria e mitigar a falta de estruturação de papéis observada durante a execução do projeto, propõe-se a adoção de uma Matriz de Atribuição de Responsabilidades, conhecida como Matriz RACI. Essa matriz classifica o nível de envolvimento da equipe técnica e do cliente em quatro frentes: Responsável (R), Aprovador (A), Consultado (C) e Informado (I), eliminando ambiguidades nas tomadas de decisão e garantindo que processos críticos, como a análise qualitativa e a implementação das respostas aos riscos, possuam donos inequívocos, alinhando-se às diretrizes do PMBOK (PMI, 2017).

Na aplicação da Matriz RACI, para a atividade de planejamento dos riscos, o gerente de projetos é o responsável, o diretor de desenvolvimento é o aprovador, o patrocinador é consultado e a equipe técnica é informada. Na identificação dos riscos, o gerente de projetos é o responsável, o diretor de desenvolvimento é consultado, o patrocinador é informado e a equipe técnica é a aprovadora. Para a análise qualitativa, o gerente de projetos é o responsável, o diretor de desenvolvimento é consultado, o patrocinador é informado e a equipe técnica é a aprovadora.

No planejamento de respostas, o gerente de projetos é o responsável, o diretor de desenvolvimento é o aprovador, o patrocinador é consultado e a equipe técnica é a responsável pela execução. Finalmente, para o monitoramento dos riscos, o gerente de projetos é o responsável, o diretor de desenvolvimento é consultado, o patrocinador é informado e a equipe técnica é a aprovadora. Essa distribuição clara de papéis visa otimizar a comunicação e a execução das tarefas, elementos essenciais para a gestão eficaz de riscos em projetos de IAM.

Em síntese, o estudo revelou que, embora o projeto de implementação de IAM tenha sido concluído com sucesso em termos de prazo e entregas, o gerenciamento de riscos ocorreu de forma predominantemente reativa e informal, sem a aplicação sistemática das diretrizes do PMBOK. A identificação, análise e tratamento dos riscos foram realizados de maneira pontual e descentralizada, com informações dispersas e ausência de um registro formal. Essa abordagem limitou a previsibilidade, a rastreabilidade e a capacidade de aprendizado organizacional, destacando a necessidade de formalização e estruturação dos processos para aprimorar a gestão de riscos em futuras iniciativas de alta complexidade tecnológica.

4. Conclusão

O presente estudo analisou o gerenciamento de riscos em um projeto de implementação de soluções de Identity and Access Management (IAM), buscando compreender como os riscos foram tratados na prática e em que medida esse processo se aproximou ou se afastou das diretrizes propostas pelo Project Management Institute (PMI), além de propor recomendações aplicáveis a iniciativas futuras. Verificou-se que o gerenciamento de riscos ocorreu de forma predominantemente reativa, com a identificação, análise e definição de respostas sendo realizadas de maneira informal ao longo do projeto. Observou-se a ausência de processos estruturados para análise qualitativa ou quantitativa e para o monitoramento contínuo dos riscos, distanciando-se das diretrizes do Project Management Body of Knowledge (PMBOK). Apesar da informalidade, riscos relevantes, como a incompatibilidade de APIs em sistemas legados, a indisponibilidade de especialistas e as limitações em ambientes de teste, foram identificados e tratados durante as fases de especificação e desenvolvimento, permitindo a conclusão do projeto dentro do prazo e com as entregas previstas.

A principal contribuição do estudo reside na proposta de um framework estruturado para a gestão de riscos em projetos de implementação de IAM, fundamentado nas boas práticas do PMBOK. Este framework visa promover a transição de um modelo reativo para um processo contínuo e preventivo, incluindo a formalização de um registro de riscos, a aplicação de análise qualitativa com base em probabilidade e impacto, e a definição de estratégias de resposta. A ausência de padronização e de um repositório formal de lições aprendidas limitou a previsibilidade e a capacidade de aprendizagem organizacional no projeto analisado. A adoção de práticas sistematizadas, como a Matriz RACI proposta, tende a proporcionar maior previsibilidade, melhor comunicação entre as partes envolvidas e redução de retrabalho, contribuindo para a maturidade da gestão de projetos de cibersegurança e IAM. Sugere-se que estudos futuros implementem e avaliem a eficácia do framework proposto em contextos semelhantes.

Referências Bibliográficas

Alghamdi, S.; Win, K. T. 2013. Critical success factors for implementing identity and access management systems. International Journal of Information Security 12(2): 123-134.

Bigaton, A.; Velázquez, D. R. T.; Oliveira, E. D.; Belem, M. J. X.; Ramos, M. O. 2024. Metodologias de pesquisa para trabalhos de conclusão de curso. Editora PECEGE, Piracicaba, SP, Brasil.

Gil, A. C. 2002. Como elaborar projetos de pesquisa. 4ed. Atlas, São Paulo, SP, Brasil.

International Organization for Standardization [ISO]. 2022. ISO/IEC 27001: information security management systems. Disponível em: https://www.iso.org/isoiec-27001-information-security.html. Acesso em: 15 abr. 2026.

Keeling, R. 2009. Gestão de projetos: uma abordagem global. 4ed. Saraiva, São Paulo, SP, Brasil.

Kerzner, H. 2017. Project management: a systems approach to planning, scheduling, and controlling. 12ed. Wiley, Hoboken, NJ, EUA.

National Institute of Standards and Technology [NIST]. 2017. Digital identity guidelines (SP 800-63). Disponível em: https://pages.nist.gov/800-63-3/. Acesso em: 15 abr. 2026.

Project Management Institute [PMI]. 2017. A guide to the project management body of knowledge (PMBOK guide). 6ed. Project Management Institute, Newtown Square, PA, EUA.

Rabechini Jr., R.; Carvalho, M. M. 2013. Relacionamento entre gerenciamento de risco e sucesso de projetos. Revista Produção 23(3): 570-581.

Raz, T.; Hillson, D. 2005. A comparative review of risk management standards. Risk Management 7(4): 53-66.

Sampieri, R. H.; Callado, C. F.; Lucio, M. P. B. 2013. Metodologia de pesquisa. 5ed. Penso, Porto Alegre, RS, Brasil.

Sommerville, I. 2011. Software engineering. 9ed. Pearson, Boston, MA, EUA.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Gestão de Projetos do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy