Como uma das partes interessadas mais importantes de qualquer iniciativa é o cliente, é fundamental mantê-lo informado e envolvido em tudo o que está acontecendo, não concorda? É impensável pensar, por exemplo, que a gestão de um projeto pode ser bem-sucedida sem que se tenha atendido as expectativas do contratante e feito uma boa manutenção da gestão de clientes! Então, nada mais essencial que estabelecer relações estreitas com esse decisivo stakeholder.

Por essas e outras, a organização, o gerente e a equipe devem mover montanhas para captar quais são as impressões, as necessidades e os objetivos dos clientes. Assim será possível exercer uma boa gestão e, consequentemente, obter sucesso com o projeto. Está achando tudo muito complicado? Não se preocupe, porque não é tão difícil quanto parece! Atentando-se para as dicas que selecionamos para o post de hoje, fazer a gestão de clientes de forma correta, se tornará uma tarefa bem mais simples do que espera. Confira!

Consistência na postura

O gerente de projetos precisa agir de modo firme, sabendo exercer sua liderança tanto em relação à equipe como no que diz respeito ao cliente. Assim ele se torna uma referência como sendo o direcionador dos esforços para a produção de tudo aquilo que deve ser entregue. Esse comportamento, além de contribuir para a finalização gradual do escopo, permite que a gestão de projetos conquiste e trabalhe em conjunto com a gestão de clientes.

A propósito, as periódicas reuniões normalmente realizadas são ótimas oportunidades para o gestor exercitar essa habilidade, mostrando seu comprometimento com os resultados e evidenciando sua preocupação junto a esse importante stakeholder.

Outro ponto importante é que uma postura consistente impede a ocorrência do engessamento dos processos, fenômeno que ocorre quando a equipe adota diferentes metodologias ou normas em diversos pontos do projeto. Esse contexto torna as atividades mais burocráticas do que deveriam ser e atrapalham, principalmente, a fluidez das interações com fornecedores externos ou com os próprios clientes do projeto.

Diferenciação das partes

Os clientes obviamente têm um interesse expressivo nos resultados da iniciativa. E vale lembrar que isso inclui não só a empresa contratante que efetivamente fará uso do produto final, mas também o patrocinador ou qualquer outro executivo que disponibilize recursos para um projeto interno.

Com isso em mente, a equipe deve saber diferenciar bem o que abrangem os termos partes interessadas e clientes, de forma a ter consciência de que esses últimos são indivíduos com necessidades dos serviços da equipe, bem como da entrega no final do projeto. Com base nessa premissa, a organização passa a ter condições de melhor atender e priorizar as demandas.

Estabelecimento de valores

Mas não basta apenas saber diferenciar o cliente das demais partes interessadas, é necessário saber o que exatamente o cliente entende como importante. É necessário desenvolver a gestão de clientes. Isso automaticamente torna as ações dos gerentes de projeto mais conscientes. O entendimento dos critérios de valor é crucial, devendo ser definidos em conjunto com o cliente, de acordo com suas próprias percepções sobre o que é ou não importante.

Tendo a gestão de projetos focada em tais critérios de valor, os serviços podem ser alinhados às exigências e às necessidades dos clientes. Já que projetos são feitos por pessoas para outras pessoas, manter um diálogo aberto e claro entre os envolvidos é essencial para garantir que o resultado estará de acordo com as expectativas das partes.

Informações de status

É importante manter o cliente informado sobre o status do projeto, o andamento das atividades e os marcos alcançados. Acredite: relatórios simples já podem evitar muitas confusões e mal-entendidos. Ao mesmo tempo, uma notícia comunicada em tempo hábil pode viabilizar uma intervenção a solicitada pelo cliente.

Por meio de reports periódicos, o cliente tem a oportunidade de fornecer feedback sobre o cronograma e também, se for o caso, questioná-lo. Não importa qual seja a ferramenta utilizada para manter essa atualização, o que é preciso guardar é que clientes participativos e comprometidos são também vitais para o sucesso do projeto.

Necessidade de auditoria

Em determinado momento (principalmente no caso de projetos internos), o cliente poderá questionar sobre a aplicação do dinheiro. Onde exatamente cada parte do orçamento foi investida? Nessa hora, ter um projeto bem auditado faz toda a diferença. Muitos gestores consideram desnecessário exercer um controle minucioso de gastos, contudo, na medida em que o dinheiro vai sendo consumido, pode acabar surgindo um buraco negro se não houver um monitoramento de onde o capital foi aplicado. Nesse contexto, como explicar?

Como essa é uma situação que, com certeza, comprometeria muito a relação do gestor com o cliente, é necessário definir padrões sobre como o projeto será acompanhado, quais processos precisam ser estabelecidos e seguidos. Do contrário, dados importantes podem se perder, frustrando não só a credibilidade junto ao cliente como prejudicando a formação de índices comparativos para o uso em empreendimentos futuros.

Gestão de fornecedores

Assim como é necessário realizar uma boa gestão da equipe, o gerenciamento dos recursos externos também é importante. Por mais que seja comum contratar fornecedores, terceirizando alguns trabalhos, a gestão desses stakeholders não pode ser delegada. A principal vantagem de contratar um terceiro é a possibilidade de transferir a responsabilidade de entrega (desde que o contratado tenha capacidade para tal, é claro). Contudo, é fundamental que o gerente de projetos tenha movido esforços para deixar claro aquilo que é valor, ou seja, o que é realmente importante para o cliente final.

Esse é o aspecto mais importante ao contratar um parceiro para fornecimento: explicitar que existe um padrão de entrega que deve ser atingido tendo como foco as necessidades e expectativas do cliente. Para tanto, a gestão deve considerar a especificação de métricas de qualidade e, é claro, definir muito bem os prazos para os fornecedores.

Como você pôde perceber, maiores ganhos e melhores resultados podem ser alcançados quando se estabelece um adequado relacionamento com o cliente, ou seja, quando existe a gestão de clientes. É fundamental que haja diálogo e real compreensão daquilo que é requisito de sucesso para os participantes do projeto. E não só o gestor como também a equipe toda devem reconhecer os clientes não como geradores de aborrecimentos, mas sim como membros de uma relação de cooperação e parceria, frutífera para ambos os lados!

Agora nos conte aqui, como anda a relação gestão de clientes na sua empresa?

Muitos desenvolvedores passaram a adotar metodologias ágeis para aumentar a velocidade de entrega de suas soluções de TI. Trabalhando com rotinas como o Scrum, eles se tornaram capazes de atuar lado a lado em busca de uma estratégia mais robusta, segura e que permitisse a entrega contínua de partes do produto, todas completamente funcionais.

Neste cenário, o sprint se integra ao método Scrum como uma forma de facilitar a divisão de um projeto em etapas ao longo do tempo. Com reuniões diárias, definição de metas e um bom fluxo de trabalho, o time de desenvolvimento pode criar um software diferente com a agilidade necessária para os tempos modernos.

Além disso, o uso de sprints permite uma melhor classificação de prioridades, hábito extremamente útil em atividades mais complexas ou que envolvam um número maior de pessoas. A classificação de prioridades, no caso do Scrum, tem a participação de toda a equipe, em diferentes partes do processo de planejamento, o que democratiza e torna mais eficiente o processo.

Quer saber mais sobre sprints e como essa prática da metodologia Scrum pode ajudá-lo no seu dia a dia? Acompanhe:

Afinal, o que é um sprint?

Um dos pilares de um projeto de desenvolvimento baseado na metodologia Scrum consiste em sua divisão em etapas. Cada uma dessas fases possui um tempo definido, que pode ser um ciclo com duração de uma semana, duas semanas ou até um mês.

O sprint pode ser considerado o principal evento do método Scrum, porque é nele que serão aplicados os demais eventos, utilizados os artefatos produzidos anteriormente e desenvolvido de fato o produto. É nele que ocorre a produção de um produto ou parte dele.

Esses são os sprints! Eles não só devem possuir um conjunto de requisitos e metas a serem implementados pelos desenvolvedores, como também, precisam buscar o desenvolvimento de funções, de acordo com a ideia de sistema do cliente.

E como realizar um sprint?

A criação de um sprint envolve um trabalho constante de comunicação entre os times de desenvolvimento, o Scrum Master e o Product Owner. Eles devem compartilhar suas necessidades, sua capacidade de produção e sua evolução no alcance das metas, a fim de evitar a quebra de expectativas ao final de cada etapa.

No entanto, antes de se criar os sprints de um projeto, é preciso definir quais são as funcionalidades do produto a ser desenvolvido e que são desejadas pelo Product Owner. Para isso, constrói-se um artefato chamado Product Backlog, que contém as principais características do produto a serem desenvolvidas.

O Product Owner também tem a função de definir as prioridades do Product Backlog feito por ele. Assim, uma vez que todas as funções do backlog estejam classificadas de acordo com as prioridades de cada parte, a primeira reunião do time de desenvolvimento com o Product Owner é realizada.

Alinhamento

Compartilhando informações, os profissionais deverão alinhar com o Project Owner quais funções serão implementadas, assim como as tarefas a serem executadas. Essa parte é chamada de Sprint Planning. Ele é o primeiro evento realizado no sprint, e deve responder duas perguntas primordiais para o decorrer do método Scrum: o que será feito? Como será feito?

Logo, o Sprint Planning é dividido em duas partes, cada uma com tempo sugerido de quatro horas. A primeira definirá quais os itens do Product Backlog serão desenvolvidos no sprint. Enquanto a segunda parte, definirá como esses itens serão abordados durante o trabalho, ou seja, quais serão as tarefas executadas para que os elementos selecionados sejam entregues no fim dessa etapa.

O resultado é um novo Backlog, que se caracteriza por ser uma parte do Product Backlog, porém, com maior detalhamento de tarefas e funções para cada item selecionado. Esse novo artefato gerado a partir da reunião inicial do sprint é chamado de Sprint Backlog.

Normalmente, a atribuição de prioridades nos Backlog é feita por pontuação. Tarefas mais importantes para o Product Owner, mais difíceis de executar, mais demoradas ou que possuem alguma incerteza ou risco técnico recebem maior pontuação.

Cada Scrum Team tem uma pontuação limite aferida, com base na produtividade da equipe. Com isso, o grupo fica limitado a pegar um conjunto de tarefas que não exceda o limite. Esse parâmetro é criado para diminuir o número de tarefas não entregues devido ao sobrecarregamento da equipe.

Assim que o Product Owner define os itens do Backlog a serem desenvolvidos, fica a cargo do Scrum Team dizer o que é possível de ser entregue dentro do prazo final do sprint. Nesse ponto, é necessário que o time aceite apenas uma quantidade de tarefas que não exceda a pontuação máxima que a equipe é capaz de desenvolver.

Em alguns casos, pode ser mais interessante dar prioridade para as atividades que envolvem um maior risco técnico ou de segurança. Em outros casos, os gestores podem optar por priorizar os trabalhos que agregam mais valor ao produto. Nesse momento, a opinião do Product Owner deve ser levada em consideração.

Duração

No método Scrum, todo evento ou processo é Time-boxed. Ou seja, tudo que será realizado no método tem uma duração, um prazo pré-definido, determinado com base em uma análise anterior ou a um padrão já conhecido de trabalho.

Assim, cada sprint deverá ter sua duração de acordo com a capacidade de trabalho do Scrum Team, responsável pelo desenvolvimento da arquitetura do produto. Normalmente, em equipes que estão no início da implantação do método, é adotado um período de 30 dias para a execução da carga de tarefas padrão.

Assim que ela passar a dominar o método, esse período pode ser reduzido para 21 dias e em seguida para 14 dias. É importante que a duração do sprint seja dada em semanas exatas, o que facilita a organização da equipe. Da mesma forma, as tarefas a serem feitas devem ter no máximo 8 horas, ou seja, um dia de trabalho.

Se o sprint contar com muitas tarefas, será necessário reduzir a quantidade de atividades do Product Backlog que a equipe tentará executar. Caso o número de trabalhos seja baixo, mais itens do Product Backlog podem ser adicionados ao sprint.

Trabalho

Uma vez finalizado o Sprint Backlog, as atividades são efetivamente iniciadas. Nesse momento, o Product Owner deverá se afastar um pouco do time de desenvolvimento, que subdividirá as tarefas de modo a conseguir um maior controle sobre os trabalhos a serem realizados.

O método Scrum procura criar um ambiente de trabalho que facilite a solução de problemas por meio da cooperação coletiva. Para isso, é sugerido que o Scrum Team seja composto por pessoas de diferentes áreas técnicas, a fim de criar um grupo multidisciplinar, o que estimula novas ideias e soluções.

Além disso, a comunicação interpessoal e acompanhamento de resultados devem ser bastante motivados dentro do sprint, para que não haja atrasos ou tarefas não realizadas.

Acompanhamento

Regularmente, a equipe de produção deve efetuar reuniões para discutir os avanços dos trabalhos, promover brainstorms a fim de encontrar soluções para eventuais falhas e compartilhar informações. Essas reuniões são chamadas de Daily Scrum.

Sugere-se que as Daily Scrum sejam realizadas todos os dias, durante o sprint. Nelas serão discutidos o andamento do projeto. Assim, fica mais fácil identificar rapidamente gargalos e se reorganizar para eliminá-los. Nesses encontros, o Project Owner pode até estar presente, mas não deve realizar intervenções a não ser que seja solicitado.

Progresso

A partir do Daily Scrum é possível analisar o progresso e desempenho do trabalho da equipe, buscando as soluções necessárias para os problemas. Para verificar o progresso de cada sprint, um gráfico de burndown pode ser utilizado a partir de três perguntas:

• O que foi realizado no dia anterior?
• O que será realizado hoje?
• Quais são os obstáculos que impedem o avanço do projeto?

A partir do resultado apresentado no gráfico, a equipe pode identificar se está ou não cumprindo com as obrigações firmadas no início do sprint. Caso não esteja, ela analisa o motivo desse desempenho inferior ao esperado. A equipe pode buscar solução em conjunto com o Product Owner, para que todas as etapas desejadas sejam entregues.

Teste

Para que um item seja considerado completo, ele deve ser codificado, testado e devidamente documentado. Falhas de segurança devem ser rastreadas para garantir a confiabilidade do produto, assim como bugs.

Além disso, todo código deve ser otimizado, para garantir o melhor funcionamento possível na máquina do usuário final. É no teste que o time garante que a funcionalidade está bem desenvolvida e o valor esperado será gerado. Isso vale para qualquer tipo de projeto.

Revisão

Ao final de cada sprint, o time de desenvolvimento realiza uma reunião de revisão, conhecida como Sprint Review. Essa reunião deve incluir o time de desenvolvimento, o gerente do projeto e o Product Owner para compartilhar as funções implementadas durante o sprint e apresentar os resultados obtidos.

Na Sprint Review, a equipe de desenvolvimento apresenta o tudo o que foi desenvolvido do Backlog, o que não foi desenvolvido e as dificuldades presenciadas. Normalmente, é feita uma apresentação formal em slides e reservado um tempo para o teste das plataformas já desenvolvidas.

De acordo com a avaliação do Project Owner, a equipe de desenvolvimento pode efetuar melhorias no projeto ou implementar novas funções. O que for reprovado deverá retornar ao Product Backlog, onde ficarão disponíveis para consulta futura.

Com o Sprint Review passa-se transparência ao cliente, ao mostrar o que já foi executado e o que falhou e será refeito, além de permitir que ele acompanhe as etapas de desenvolvimento, sem correr o risco de um produto final indesejado ou malfeito.

Reflexão

Após o encontro de revisão, a equipe de desenvolvimento deve se reunir com o Scrum Master para compartilhar sua opinião sobre o projeto e refletir sobre as práticas adotadas. Esse evento é chamado de Sprint Retrospective e tem o objetivo de analisar o processo de desenvolvimento do produto, não o produto em si.

• Será que podem ser empregadas em outras iniciativas?
• Quais foram os pontos positivos e negativos verificados?
• O que pode ser melhorado?

É importante que o Scrum Master encoraje todos os membros a darem a sua opinião sobre o trabalho realizado. Esse é momento de corrigirem qualquer falha processual detectada. Com isso, é possível tanto reforçar os métodos que devem ser repetidos, desde que alterados ou mesmo, abandonar de vez determinado procedimento.

As metodologias de desenvolvimento evoluíram bastante nas últimas décadas, sempre com o objetivo de atender às diversas necessidades da comunidade. Assim, seja para criar produtos mais seguros ou reduzir prazos de entrega de resultados, é sempre possível encontrar um método que atenda ao perfil de um projeto.

No caso da metodologia Scrum, os sprints são indispensáveis para garantir a qualidade dos trabalhos, pois permitem que tanto os gestores quanto os clientes acompanhem diariamente a evolução de um projeto.

Quanto mais próximos da execução do produto estão os stakeholders (os interessados no desenvolvimento do produto), quanto mais oportunidades eles têm de avaliar e participar das etapas de criação do produto, maior a chance de satisfação e sucesso do produto final.

Além disso, o método permite uma rápida mudança de foco, que auxilia na resolução de problemas, no atendimento a uma mudança repentina no mercado e na redução de retrabalhos e problemas de comunicação. Tudo isso, influencia no tempo de execução e na satisfação do cliente.

Junto aos pontos positivos externos estão também os internos. As Daily Scrum, as reuniões diárias, são ótimas chances para que as equipes identifiquem e melhorem suas práticas, implementando novas rotinas, apontando soluções para problemas críticos e aumentando a qualidade final do produto.

Além disso, a Sprint Review dá espaço para a crítica externa, dos stakeholders, que passam a ser parte fundamental do processo de construção do produto. A Sprint Retrospective fecha o sprint, sendo o mecanismo de correção de erros, discussão de novos procedimentos e afirmação do método.

Quer dicas para aliar o Scrum às boas práticas do PMBoK? Então, você gostará deste e-book.

E você, como trabalha com seu time de desenvolvimento para aumentar a eficiência dos trabalhos? Já conhecia o poder dos sprints para o Scrum? Compartilhe suas experiências e impressões conosco!

Uma das atividades mais importantes da gestão de projetos é também uma das aparentemente mais simples: o dimensionamento do tempo, ou seja, o gerenciamento de tarefas. Afinal de contas, depois que a duração das tarefas é devidamente calculada, o planejamento passa a tomar forma. E isso se alinha ao sequenciamento dos trabalhos e, consequentemente, permite a elaboração do cronograma completo do projeto.

Nesse contexto, é extremamente importante manter em mente que os esforços de gestão não são nada independentes. Assim, ao calcular a conclusão de uma demanda em 10 dias em vez de 5, por exemplo, é possível aumentar a força de trabalho em tempo hábil. Ou seja, os recursos humanos e a organização da equipe como um todo estão intimamente ligados ao gerenciamento de tarefas conectado com o tempo.

Mas uma gestão de projeto realmente eficiente tem como premissa estimar valores realistas, o que quer dizer que não basta determinar o tempo com base em suposições infundadas ou em palpites simplistas. Lembre-se: é o nível de precisão dessas estimativas que determina a confiabilidade do planejamento. Que tal aprender a atingir esse nível? Então confira as dicas que separamos para o post de hoje, que certamente o ajudarão a compor estimativas assertivas, proporcionando um gerenciamento de tarefas consistente e o consequente sucesso do projeto! 

Regra geral da divisão das tarefas

Antes que qualquer empenho seja empreendido no sentido de estimar tempo, o gestor deve estar seguro de que a atividade foi dimensionada adequadamente. É preciso ter bastante cuidado para que uma tarefa macro seja quebrada em atividades menores, porque só isso já contribui para a organização geral, tornando o trabalho melhor gerenciável. Caso contrário, os esforços envolvidos tanto na elaboração do plano como em sua execução se tornam desnecessariamente maiores.

Imagine, por exemplo, que no projeto de construção de uma casa a fase do acabamento não seja dividida em unidades menores. Nesse caso, a atribuição de recursos humanos ficaria comprometida por requerer diferentes disciplinas de mão de obra. Nesse caos, o monitoramento sofreria prejuízos por ter que medir diferentes trabalhos em uma única unidade. O ideal seria criar, então, subdivisões, tais como: “reboco”, “massa corrida” e “azulejos”. Percebe a diferença?

Essa diluição contribui para a redução do nível de complexidade da demanda, assim como dos riscos envolvidos. É como lidar com um problema complexo, mas em partes menores. Dessa forma, o que era grande acaba se tornando pequeno e totalmente sob controle.

Estimativa análoga ou top-down

Essa estimativa pode tanto ser aplicada a um projeto como um todo como somente a uma tarefa. Assim, no caso do panorama mais amplo, se os últimos 3 projetos similares foram concluídos em 14 meses, por exemplo, é provável que esse próximo projeto também se estenda por esse prazo. E no caso mais restrito, aplicado apenas a uma tarefa, a lógica é a mesma: se nas ocasiões em que essa atividade foi desempenhada foram consumidos 5 dias, logo, essa deverá ser a duração considerada.

A técnica em questão se baseia no exame de documentos, registros, lições aprendidas de projetos passados, dados de concorrentes ou de demais organizações que desempenharam trabalhos parecidos. Com base nesse levantamento histórico é possível estabelecer uma estimativa mais confiável. E por ser um método que tem como suporte apenas a consulta de informações, apresenta como vantagem uma dupla economia: de tempo e de pessoal envolvido.

Consulta a opiniões especializadas

Caso não exista domínio por parte do gerente de projetos ou mesmo se houver qualquer tipo de insegurança sobre o assunto, convém considerar a intervenção de especialistas — que podem ser os próprios membros da equipe ou terceiros contratados. Pense bem: se não há conhecimento suficiente, arriscar com base em suspeitas ou presunções não é nada prudente, além de não ser essa a postura esperada de um gestor responsável.

Guarde desde já o seguinte: é necessário, antes de mais nada, ter cautela e reconhecer as próprias limitações. Dessa forma, quando não há consenso ou não se tem a noção adequada da complexidade da demanda, a avaliação especializada de consultores pode sim ser a melhor alternativa, buscando identificar as variáveis envolvidas e prever a duração do trabalho.

Estimativa de três pontos ou técnica PERT

A técnica de PERT (Program Evaluation and Review Technique) leva em consideração três cenários possíveis para determinar o tempo de uma atividade: duração pessimista (P), duração otimista (O) e duração mais provável (MP). Esse método também pode contar com o suporte de opiniões especializadas citado acima e, inclusive, ser usada também para as estimativas de custo. É dada pela fórmula (P + 4 x MP + O) / 6 e o resultado fornece a duração esperada.

Note que a fórmula atribui peso 1 para os contextos pessimista e otimista, enquanto atribui peso 4 ao cenário mais provável. E ainda assim o peso pode ser alterado, desde que a soma não ultrapasse 6, conforme a realidade do projeto ou a tolerância a riscos do gestor. A fórmula do desvio padrão — dada por P – O / 6 — também pode ser aliada a essa técnica com o objetivo de chegar ao intervalo da estimativa. Digamos, por exemplo, que com a técnica de PERT tenham sido calculados 9,5 dias para a tarefa X. Nesse caso, sendo a duração otimista igual a 10 e a pessimista igual 15, o desvio seria de 0,8. Assim, a tarefa levaria 9,5 + 0,8 ou 9,5 – 0,8 dias, que é igual ao intervalo entre 8,6 a 10,3 dias.

Estimativa paramétrica

Para a utilização dessa técnica surge a necessidade de se trabalhar com dados muito bem consolidados, sob o prejuízo de o método se tornar impreciso. Afinal de contas, essa metodologia observa os relacionamentos entre as variáveis e uma determinada atividade para calcular as estimativas. Dessa forma, se o desenvolvedor João escreve 50 linhas de código por dia, por exemplo, naturalmente se conclui que ele desenvolverá 500 linhas de código em 10 dias, certo?

O segredo está em, sempre que possível, calcular a duração das atividades com o apoio do time envolvido. Isso gerará maior credibilidade e engajamento dos integrantes. Claro que sabemos que é impossível definir com extrema exatidão a data em que um projeto será terminado, mas é plenamente factível alcançar valores bastante próximos. E esse deve ser o foco do gerente de projetos. Se não for dessa forma, o planejamento se torna figurativo, desacreditado e sem valor para a organização.

É importante ainda ressaltar que o cronograma, o gráfico ou qualquer outro documento que contenha a duração das atividades requer a publicidade necessária, não devendo ser um arquivo ou uma ferramenta de uso exclusivo do gerente de projetos. Os prazos a serem atendidos devem ser facilmente visíveis por todos, permitindo o acompanhamento da produtividade esperada por parte da equipe, assim como suas responsabilidades. Dessa forma, os colaboradores adquirem um maior senso de urgência e de priorização, que poupam a necessidade de intervenção contínua para o gerenciamento de tarefas por parte do GP.

E você, por acaso conhecia todas essas técnicas? Já teve a oportunidade de usar alguma delas em seus projetos? Comente aqui e compartilhe suas experiências conosco!

Os projetos de sua empresa, quando bem delineados, têm seu prazo de conclusão definido logo no desenvolvimento do escopo. Contudo, quando analisamos a realidade, é comum nos depararmos com muitos projetos que nunca acabam. Os motivos para isso são diversos: má definição dos objetivos, mudanças de mercado durante o desenvolvimento, um novo posicionamento estratégico pela empresa, falta de recursos, dentre vários outros fatores.

Se identificou com esta realidade e não sabe como resolver este problema? Então você não pode perder este post com 5 dicas para encerrar aqueles projetos que nunca acabam!

1) Redefina um prazo final conforme as variáveis necessárias para a conclusão

Existem dois tipos de projetos: os de prazo determinado e os de caráter contínuo. Os do segundo tipo são mais raros. Por isso, para a maioria dos projetos é necessário definir uma data para que ele se encerre. Caso os objetivos não tenham sido alcançados, reavalie, faça modificações e crie um novo prazo, levando em consideração os fatores que impediram a conclusão com sucesso. Para isso, evite manter tarefas abertas por “tempo indeterminado”. O prazo permite planejar os recursos que serão investidos e as prioridades da empresa.

2) Estabeleça metas intermediárias

Mesmo definindo um prazo final para o seu projeto, a equipe pode acabar se perdendo no meio do caminho. É isto o que, geralmente, acontece quando há constante revisões de prazos. Neste caso, o prazo não vale de nada porque não é cumprido. Para evitar este problema, defina metas intermediárias e também dê prazos para a conclusão delas.

Com esta definição você consegue saber exatamente em que ponto está o projeto, onde serão necessários ajustes e o que precisa ser feito para que ele seja concluído dentro do prazo estimado. Se a equipe conseguir cumprir todas as metas intermediárias, você saberá que o objetivo final será cumprido dentro do prazo estabelecido. Na situação inversa, você visualizará uma oportunidade para a definição de um plano de ação que contribua para reverter o caso.

3) Crie maneiras de medir o desempenho

Além de criar as metas intermediárias, é preciso também desenvolver maneiras de medir o desempenho de sua equipe no projeto. Quantas horas estão sendo gastas em cada atividade por cada um dos funcionários? Elas estão de acordo com o planejado? Quantos recursos estão sendo investidos em cada parte do projeto? Ele está sendo suficiente para a conclusão dos objetivos?

A partir destes e de outros dados você conseguirá realocar os recursos sempre visando o cumprimento das metas intermediárias e do prazo final. Nesta questão, um software para o gerenciamento dos projetos é a melhor ferramenta para fazer essas medições de forma rápida e integrada com outros processos.

4) Mantenha vivo os canais de comunicação

A falta de comunicação é uma das principais raízes de problemas de todos os tipos nas empresas. Não seria diferente em relação aos projetos que nunca acabam. Um gerente de projetos deve favorecer ativamente os canais de comunicação entre os funcionários e com ele próprio, para que a equipe possa apresentar suas dificuldades e cooperar para buscar soluções para os problemas. Trabalhar de forma colaborativa é uma excelente estratégia para manter o time mais envolvido e comprometido com as entregas!

5) Reavalie as necessidades

Muitas vezes o problema de projetos que nunca acabam é de solução bastante fácil: simplesmente termine-o. Alguns projetos, especialmente os de caráter contínuo, vivem indefinidamente quando não há sequer necessidade que eles existam. Por isso, é preciso fazer uma avaliação contínua sobre a real função de cada um dos projetos abertos para os objetivos da empresa.

Mesmo que um projeto não tenha cumprido seus objetivos originais, muitas vezes a melhor solução é simplesmente encerrá-lo ou mesmo considerar a reavaliação de necessidade e prioridades. A economia de tempo, dinheiro e a possibilidade de focar no que realmente importa são compensadoras.

Como vimos, com exceção dos que possuem caráter contínuo, todos os projetos devem ter um fim. Caso contrário, serão consumidos muitos recursos e o objetivo não será alcançado de maneira satisfatória. Para evitar este problema, sempre estabeleça um prazo final e metas intermediárias. Também tenha maneiras de avaliar o desempenho e recursos gastos em cada etapa do projeto, além de manter vivo seus canais de comunicação. Por fim, sempre esteja aberto para encerrar projetos que já se estenderam por tempo demais, mesmo que eles não tenham cumprido seus objetivos ou rever todas as questões que os envolvem, visando maneiras de concluí-los com excelência.

E você, já se deparou com este tipo de situação? O que fez para resolver estas questões? Complemente nossas dicas através dos comentários abaixo!