Habilidades de gestão de projetos são muito importantes para analistas de business intelligence, pois em muitos casos as áreas de conhecimento da gestão de projetos se tornam essenciais para construir bons produtos e até em alguns casos implantar boas práticas em operações desse nicho.

O Que é um Projeto?

Projetos têm algumas características, mas podemos dizer que as principais são que eles têm início, meio e fim. Como exemplo, podemos utilizar a construção de dashboards.

Uma indústria de alimentos pode encomendar um dashboard para visualizar com determinada periodicidade números importantes de sua operação, para tomadas de decisão no dia a dia, com indicadores de performance importantes para a produção.

Para isso, o analista responsável por construir esse artefato pode elaborar um projeto, com todas as boas práticas envolvidas, de modo a entregar um produto com qualidade e que atenda as expectativas dos stakeholders.

Stakeholders são as partes interessadas no projeto. Geralmente, o cliente e sua equipe que irá utilizar o produto final.

Qual a Estrutura de um Projeto de Business Intelligence?

Em um projeto tradicional com modelo preditivo, ou seja, aquele que você sabe onde chegará, o analista pode usar o modelo cascata, com as fases de Iniciação, elaboração, execução e entrega. Já em projetos onde existe alguma incerteza, algo novo, que nunca tenha sido feito por aquela equipe ou sua organização, o modelo ágil parece ser mais promissor.

Como posso entender qual o tipo de projeto eu tenho? Basta usar o Cynefin. Ele pode ajudar a entender o tipo de problema existente e o nível de certeza ou incerteza presente. Entendendo o domínio do problema ficará muito mais fácil determinar qual o tipo de projeto.

Como Iniciar a Montagem de um Projeto de BI?

Seguindo o exemplo do desenvolvimento de um dashboard para a indústria de alimentos, que comentei anteriormente, podemos considerar que a organização vai contratar uma empresa para montar esse recurso. A equipe que irá desenvolver sabe onde vai chegar, afinal, já foram desenvolvidos outros dashboards. Temos aqui um projeto que podemos usar um modelo cascata, considerando seu modelo preditivo.

Início:

É importante entender, em um início de projeto de BI, o escopo, expectativas, riscos, a viabilidade desse projeto em uma organização, entre outros aspectos.

No início desse projeto, minha sugestão é que exista uma reunião de briefing para entender a demanda. A encomenda, por parte dos stakeholders, vem sempre com a ideia do produto final e uma expectativa de prazo.

O gerente de projetos, responsável pelo desenvolvimento do dashboard da indústria de alimentos, vai convocar uma reunião de briefing para entender quais as necessidades dos executivos de visualizar os indicadores. Isso será importante para montar o backlog do produto e também avaliar no final se todas as expectativas foram cumpridas. 

Precisamos avaliar aqui os potenciais riscos de um projeto desses na organização. Por exemplo, a empresa tem verba para aquisição de novas tecnologias de banco de dados e contratação de funcionários?  Caso não, como será feita a viabilização desse projeto? Mediante financiamento, empréstimos, utilização de reserva? Esse é um ponto importante.

Uma matriz pode ser utilizada para definição desses riscos. Geralmente, eu gosto de colocar todos esses riscos em uma tabela, dando a eles pontuação, e reservo uma coluna para descrever os atos de mitigação. Ou seja, entendendo o escopo do projeto e a expectativa dos stakeholders, o gestor de projetos precisará montar um plano de mitigação de riscos que, no caso da indústria de alimentos, podem ser vários. Ele pode descobrir que um dos sistemas entrega os dados de uma forma totalmente diferente dos demais, com formatos de data, números, dentre outros, incompatíveis com os critérios que pensou em utilizar. Dessa forma, precisará fazer um ETL antes de enviar os dados para um data warehouse, o que poderá aumentar o custo do projeto, bem como atrasar algumas etapas. Esse é um risco que pode ser mitigado já na fase inicial do projeto, onde a solução será fazer um levantamento desse custo extra, incluindo ele no plano de custo do projeto, evitando que o cliente receba avisos de aumento na fase de execução. 

O fato é que no início de qualquer empreendimento, inclusive um projeto de BI, sempre inconscientemente avaliamos riscos mentalmente. Você nunca olhou para um projeto que ainda estava em seus primeiros passos e pensou: “Isso vai dar problema!”. Óbvio que sim. Contudo, o que sugiro aqui é uma organização e mitigação dos riscos que você pensou.

Se imaginarmos em uma curva de tempo e esforço de projeto, imagine que gerenciar os riscos na fase de iniciação é o melhor a se fazer, pois é onde eles têm menos chance de acontecer.

Elaboração e Planejamento:

O cronograma é algo vital. Entenda as atividades relacionadas com o projeto e a capacidade produtiva da equipe, ou seja, quantas horas ela leva para fazer cada atividade.

Após isso, reúna todas as tarefas em um cronograma, com seus respectivos recursos alocados e a estimativa de horas. Se for necessário, investigue a base histórica de outros projetos para ter uma referência de horas por atividade. Isso pode ajudar a elaborar o cronograma.

Uma das coisas que você pode fazer para determinar o tempo de tarefas é uma estimativa baseada em três pontos, onde fará uma média de estimativas:

• Mais provável = 3h
• Otimista = 2h
• Pessimista = 5h
• Soma = 10h
• Tempo estimado = 10/3
• Resultado= 3.3h

O mesmo pode ser usado para gestão de custos. Imagine que em um projeto de BI, no exemplo que estamos usando, será necessário fazer a aquisição de uma tecnologia de banco de dados e, também, contratar profissionais especialistas. Do mesmo modo, pode ser utilizada a técnica de três pontos.

Determine também os marcos do projeto

Marcos podem conter várias atividades mais importantes; são aqueles pontos raízes na EAP (Estrutura Analítica do Projeto).

O EAP ajuda o gerente de projeto, bem como a equipe que irá trabalhar no projeto a ter uma visão geral dos principais marcos do projeto. Note que na imagem acima, é possível verificar todos os principais marcos importantes à construção do dashboard destinado à indústria, bem como algumas das entregas importantes para a conclusão desses marcos.

O que é muito importante nessa fase?

Apresentar para o cliente o cronograma completo. 

Geralmente, no início do projeto, eu mostro ao cliente, no documento de abertura, um cronograma estimado, com algumas daquelas atividades-chave. Mas não é algo completo, nem riscado na pedra. Sendo assim, é na fase de planejamento que você vai elaborar algo mais consolidado. Ou seja, com base no EAP do projeto, teremos aquelas atividades de caminho crítico, as mais importantes. Será possível para o GP, criar as atividades com um nível de detalhamento maior no cronograma, seja aquelas de caminho crítico quanto às com menor importância, mas necessárias para o projeto.

Execução:

É aqui que as coisas começam a acontecer, e onde é necessário fazer as adaptações necessárias no planejamento. Sim, o princípio da gestão de mudanças é importante.  

O marechal de campo prussiano Helmuth Von Moltke dizia: “Nenhum plano de batalha sobrevive ao contato com o inimigo”. Isso porque a guerra é um campo de incertezas e, por mais que houvesse pesquisa, planejamento e inteligência, havia variáveis externas incontroláveis por ele.

Penso que o planejamento é o ato de manipular cenários em execução, ou seja, você planeja, mitiga o risco (incertezas) e dá um espaço de manobra para as incertezas. Sendo assim, na execução, use esse espaço quando necessário.

No projeto do dashboard, por exemplo, pode haver um sistema onde os dados são entregues através de uma API (Application Programming Interface). Nesse caso, pode ser necessário contratar um programador, pois pode ser necessário alguém com habilidades específicas para realizar esse trabalho, ou seja, algo que pode ser previsto e executado dentro dos limites do planejamento realizado.

Também é importante que o GP faça sempre a revisão do cronograma, faça atualização, compare horas estimadas e horas executadas, e o que irá entrar posteriormente na base histórica do escritório de projetos.

Encerramento do Projeto:

Lembre-se de que, se o projeto tem início, meio e fim, é importante que haja uma finalização que contemple e faça a verificação de tudo o que foi entregue.

No exemplo que estamos trabalhando do dashboard para uma indústria de alimentos:

• O gerente de projeto deve fazer a entrega do dashboard.
• Realizar o treinamento dos usuários.
• Conduzir uma reunião com a equipe que participou do projeto para discutir os destaques e lições aprendidas.
• Lidar com a liberação de notas fiscais de fornecedores e outras necessidades financeiras.
• Alocar os recursos para outros projetos, como na empresa que desenvolveu o dashboard, onde os profissionais envolvidos são designados para o desenvolvimento de outros projetos ou produtos para outras empresas.

Feito isso, o gestor deve arquivar a documentação do projeto e enviar uma mensagem a todos, marcando o encerramento do projeto e fornecendo sugestões para os próximos empreendimentos.