O que é planejamento de projetos de TI?
O planejamento de projeto de tecnologia da informação, ou planejamento de projeto de TI, é o esforço que uma equipe faz no início de um projeto para garantir que o trabalho avance bem. Essas etapas também ajudam a garantir que o projeto cumpra seu prazo e metas gerais.
O planejamento é a segunda fase de um projeto de TI, após o início do projeto e antes de sua execução. Saiba mais sobre as fases de início e execução e gerenciamento de projetos de TI. Para saber como priorizar esses projetos, visite nosso guia abrangente de priorização de projetos de TI.
Como planejar um projeto de TI
O planejamento de um projeto de TI requer etapas iniciais importantes. Isso inclui ajudar os membros da equipe e as partes interessadas a entender o objetivo geral do projeto. Além disso, esclarecendo como a equipe irá definir e monitorar o trabalho.
Etapas de planejamento do projeto de TI
Os especialistas recomendam várias etapas para planejar efetivamente um projeto de TI. Comece convocando uma reunião inicial dos membros da equipe do projeto e das partes interessadas para discutir as linhas gerais e os objetivos do projeto.
Aqui estão 13 etapas importantes no planejamento de um projeto de TI:
Etapa 1: Convoque uma reunião inicial
Uma reunião inicial é fundamental. É uma oportunidade de reunir membros da equipe, clientes e outras partes interessadas importantes para discutir os objetivos do projeto e definir as expectativas. Os participantes da reunião também podem discutir possíveis riscos.
“O que costumamos fazer nesta reunião é pedir a presença de todos os interessados”, diz Shai Shandil, fundador da consultoria softsolutions, que presta serviços de consultoria e treinamento para ajudar empresas em projetos de tecnologia.
Shandil diz que, anos atrás, ele costumava recomendar que as pessoas viessem à reunião, mesmo que tivessem que voar para chegar lá. Hoje em dia, essa exigência provavelmente está relaxada. Mas todos devem comparecer pessoalmente ou por vídeo, pois a reunião é fundamental para que todos tenham um entendimento comum sobre o projeto e seus objetivos. “Estamos tentando chegar a um ponto em que tenhamos uma compreensão padrão do que deverá ser entregue”, diz Shandil.
Para saber mais sobre o planejamento de uma reunião inicial, leia nosso guia abrangente para lançamentos de projetos e baixe os modelos gratuitos de lançamentos de projetos.
Etapa 2: Assegure-se de ter a adesão e o envolvimento da liderança
A liderança da empresa deve mostrar que está dedicada ao projeto e considera o trabalho importante. Os líderes também devem estar envolvidos no projeto. Eles devem participar de sessões de atualização e dar sua opinião.
A adesão da liderança “é o mini passo”, diz Shandil. “Falo sobre o envolvimento profundo da liderança, e tem que ser comparável ao orçamento que eles estão dispostos a liberar. Se eles estão investindo cinco dólares, então com certeza – se eu cometer um erro aqui, tudo bem. Mas se eles estão investindo milhões e trata-se de 80% do orçamento total, então você está começando a pensar: 'Eu não posso deixar você vir uma vez por trimestre ou uma vez por mês e olhar alguns relatórios. Isso não é suficiente. Preciso que você esteja lá conosco para dar orientação porque você traz a visão.”
Shandil diz que isso não significa que a liderança esteja em todas as reuniões do Scrum ou em outras reuniões do projeto. “Mas o que queremos é que eles apareçam a cada duas semanas e vejam as coisas que estamos lançando”, diz ele. “Seja qual for a cadência – se forem duas semanas, quatro semanas ou três semanas – a ideia é: ‘Venha e entre em contato conosco e veja o produto.’ Eles realmente olham para ele – não um substituto para o produto, não um conjunto de slides de PowerPoint, mas o produto real. Precisamos que você vá ao conselho administrativo, ao cliente ou ao mercado e diga: 'Ei, é isso que estamos fazendo.'”
Etapa 3: Crie um termo de abertura que inclua os objetivos
É essencial criar um termo de abertura antes de começar a trabalhar em um projeto. Esse termo dá detalhes sobre escopo, recursos e cronogramas. Talvez mais importante ainda, ele define os objetivos principais do projeto. Você e sua equipe precisam ter certeza de que esses objetivos assumidos são os objetivos corretos.
“Um dos aspectos mais críticos do planejamento de um projeto de TI é entender claramente os objetivos do projeto”, diz Alan Zucker, diretor fundador da Project Management Essentials, que tem mais de duas décadas de experiência em gerenciamento de projetos em empresas da Fortune 100. “Os objetivos são 'o que queremos' e 'por que queremos'. O escopo é o 'como vamos entregá-lo.' Compreender os objetivos é importante porque pode haver várias soluções para resolver o problema e queremos entender o problema antes de decidir como resolvê-lo.
“Comece com o ‘porquê.’ Comece com o ‘porquê. Faça perguntas. O que o cumprimento desse objetivo nos permitirá fazer? O que esperamos alcançar?”
Etapa 4: Estabeleça a prova de princípio
Uma parte importante da compreensão e definição de objetivos é entender completamente o produto que seu projeto de TI deve desenvolver. Você deve ter certeza de que o produto é tecnicamente possível e vale a pena.
“Certifique-se de que há clareza sobre o que você deseja entregar”, diz Zucker. “Uma prova de princípio – isso será inestimável.”
“Faça uma prova de conceito [do produto]”, diz Patrick Sim, cofundador da RobustTechHouse, que desenvolve projetos de TI para clientes, e da FacilityBot, que usa tecnologia para ajudar a gerenciar instalações e fábricas. “E faça isso primeiro. Se você não puder fazer isso, então esqueça.”
Se você não puder tecnicamente fabricar o produto ou tiver problemas para vendê-lo pelo preço necessário para cobrir os custos, precisará saber disso desde o início, explica Sim. E você pode precisar encerrar o projeto. “Passe para outra coisa”, diz ele.
Etapa 5: Estabeleça um orçamento (mas entenda que pode precisar mudar)
Será conveniente estabelecer um orçamento amplo para o projeto. Mas crie uma estrutura e processos que permitam que o orçamento mude quando necessário. Isso é particularmente importante para projetos de TI porque os produtos geralmente evoluem à medida que se desenvolvem.
Os especialistas também apontam que uma característica fundamental dos projetos (e produtos) de TI é que o orçamento aumenta à medida que o projeto é bem-sucedido.
“Uma questão-chave é que projetos de TI bem-sucedidos são bem utilizados e geralmente exigem novos recursos e melhorias contínuas”, diz Sim. “Custos adicionais continuarão a ser incidir – especialmente para projetos de TI bem-sucedidos. Todos os produtos de sucesso que você vê por aí... eles estão sempre adicionando recursos, certo? Portanto, o orçamento tem que aumentar. Isso é parte da adesão que a administração precisa entender.”
Etapa 6: Estabeleça o escopo do projeto
Depois de definir seu objetivo e o orçamento provisório, é hora de estabelecer o escopo exato do projeto. Você definirá os parâmetros do que o projeto produzirá ou concluirá e o que ele não fará.
“Uma vez que tenhamos uma compreensão de o que é desejado e por que, podemos começar a fazer perguntas sobre o escopo”, compartilha Zucker. “Podemos começar a olhar para o escopo do projeto de alto nível. O que está no escopo? E, muitas vezes tão importante quanto essa informação, o que está fora do escopo?”
Você pode baixar um modelo para ajudá-lo a detalhar o escopo de um projeto de TI.
Etapa 7: Crie um plano de gerenciamento de projetos
Depois de determinar os objetivos, o orçamento e o escopo, você pode concluir um plano de gerenciamento do projeto. Este plano oferece uma estrutura geral de como realizar o trabalho.
“O plano de gerenciamento do projeto deve ser personalizado ou adaptado ao projeto específico”, diz Zucker. “É o guia do gerente de projeto para executar o projeto.”
Visualize e baixe modelos gratuitos de gerenciamento de projetos para ajudá-lo a criar um plano de gerenciamento de projetos.
Etapa 8: Articule as responsabilidades dos membros da equipe desde o início
O plano de gerenciamento do projeto incluirá informações básicas sobre quem é responsável por quais tarefas e prazos. É vital que cada membro da equipe entenda, desde o início, as tarefas pelas quais é responsável.
Etapa 9: Decida sobre a melhor metodologia para o seu projeto
No início do processo de planejamento, você deve decidir qual metodologia de gerenciamento de projetos usar. Provavelmente será Agile ou uma versão modificada dele. Alguns projetos de TI ainda usam métodos mais tradicionais.
Zucker aconselha perguntar “que tipo de projeto estamos executando e que tipo de metodologia vai se encaixar bem com este projeto”. Para muitos projetos de TI, isso significa Agile ou alguma versão dele, que permita as mudanças e adaptações contínuas que fazem parte de um projeto de TI.
Zucker acrescenta que “determinar se este projeto será Agile ou tradicional é uma decisão que pode ser tomada por você”, porque muitas organizações têm preferência pela metodologia que usam para gerenciar projetos.
Para uma pequena minoria de projetos de TI, o gerenciamento tradicional de projetos – incluindo a metodologia Waterfall – pode ser melhor, compartilha Shandil. “Essas tendem a ser as verticais que têm menos mudanças e são altamente regulamentadas”, explica ele. “Os bancos são um exemplo disso. Trabalhei com uma empresa que basicamente vendia empresas on-line. Com as regulamentações do mercado de ações... todas essas coisas quase nunca mudam. Eles se consideravam um nicho e estavam indo incrivelmente bem. E nós dissemos: ‘Vocês deveriam continuar fazendo Waterfall; funciona muito bem.’”
Etapa 10: Plano para realizar reuniões estratégicas regulares recorrentes
Você precisa realizar reuniões regulares de check-in com todos no projeto, incluindo clientes e partes interessadas. Os especialistas recomendam realizar essas reuniões pelo menos uma vez por trimestre ou com a mesma frequência mensal para equipes menores.
Etapa 11: Estabeleça as especificações do produto
Primeiro, defina seus objetivos e garanta que o produto em que seu projeto está trabalhando seja viável. Em seguida, liste as especificações do seu produto em detalhes significativos.
“O mais importante são as especificações”, diz Sim, da RobustTechHouse. “Qual é o projeto? O que vai ser produzido? Você ficará surpreso que muitos clientes – eu diria 60% a 70% – não têm isso, na verdade.”
Os clientes que podem ser menos experientes em tecnologia ou ter menos experiência em tecnologia geralmente definem especificações em um nível extremamente alto e geral. Eles precisam ser mais específicos sobre o que o produto fará, como fará e as métricas de como e o fará, afirma Sim. “Sem um documento de requisitos detalhado, o orçamento – tanto de tempo quanto de custo – se torna muito difícil”, diz ele.
Em contrapartida, organizações maiores têm um problema diferente: muitas pessoas com opiniões diferentes sobre o produto e o que ele deve fazer. “Às vezes, as grandes organizações têm toda essa burocracia e muitas pessoas têm opiniões diferentes sobre o que deve ser feito”, acrescenta Sim. "Eles não podem chegar a um consenso sobre 'OK, este é o produto que queremos criar.' Então (é importante) chegar ao estágio de boas especificações.”
Etapa 12: Compreenda e aborde riscos técnicos e outros riscos
A equipe do projeto precisa entender rapidamente os maiores riscos para o sucesso do projeto (ou produto). Eles podem ser técnicos ou outros tipos de riscos. A equipe vai querer entendê-los e abordá-los para evitar falhas.
Os riscos técnicos — a tecnologia não funcionará corretamente devido a limitações ou problemas técnicos — são especialmente importantes em projetos de TI. Os especialistas sugerem que as equipes identifiquem e trabalhem nesses possíveis riscos com antecedência para evitar desperdício de dinheiro em um projeto fadado a ter problemas.
“Identifique os riscos técnicos com antecedência e teste se (o produto) pode ser concretizado”, sugere Sim. “É possível adicionar mais pessoal ao longo do caminho. Mais importante do que isso é identificar os principais riscos técnicos – qualquer área específica na qual a equipe técnica não tenha muita experiência – e criar esse componente primeiro.”
Shandil concorda. “Você pega a coisa mais arriscada que seja a mais importante para o cliente e a faz primeiro”, explica ele. “Digamos que estamos criando um sistema de contabilidade. Parte do risco é manter os dados confidenciais do cliente. Em seguida, construímos essa parte do sistema de contabilidade primeiro, lançamos e garantimos que funcione. Você gerenciou o risco colocando-o na frente de tudo e certificando-se de que todas as suposições que você fez em torno das leis de privacidade etc., em toda a organização ou país — eles estão sendo tratados em primeira mão. Você não pode chegar ao fim de um projeto e ter problemas desconhecidos e intangíveis.”
Etapa 13: Obtenha feedback do usuário com antecedência e frequência
Quando sua equipe está construindo um novo produto de TI, é essencial verificar como ele está funcionando (ou não) o quanto antes. Isso significa obter feedback do usuário à medida que você cria o produto.
Os especialistas recomendam criar o produto mínimo viável. Isso significa colocar o novo produto nas mãos dos usuários o mais rápido possível, mesmo quando apenas um ou dois recursos básicos estiverem funcionando. Com seus comentários sobre essa versão inicial, os usuários ajudarão você a desenvolver ainda mais o produto.
“Coloque-o no mercado antecipadamente e obtenha feedback real do usuário”, acrescenta Sim. “Muitos projetos ficam presos nos tormentos do orçamento e da engenharia de recursos e nunca começam.”
Shandil diz que muitas empresas pagarão aos usuários em potencial para experimentar o novo produto a fim saber quais serão suas reações. Com um novo sistema contábil, por exemplo, “sua estratégia pode ser conversar com contadores e dizer: ‘Olha, estamos lançando este produto. Você poderia vir e fazer um teste – pagando US$ 20 por hora ou o que quer que seja – só para usar e me dar sua opinião específica sobre como isso funcionaria em um ambiente de nuvem?” Chamamos isso de entrevistas com usuários. Mas, basicamente, é um ciclo de feedback que possibilita reduzir os riscos de forma rápida, barata e fácil.”
Componentes tradicionais de gerenciamento de projetos que são diferentes no Agile para projetos de TI
O planejamento para gerenciamento de projetos mais tradicional, como o uso da metodologia Waterfall, inclui várias etapas e documentos. Esses esforços são menos comuns ou aplicados de forma diferente quando os projetos de TI usam a metodologia Agile.
Por exemplo, as equipes costumam usar uma estrutura de divisão de trabalho (WBS) no gerenciamento de projetos tradicional. O diagrama detalhado mostra todas as tarefas que uma equipe precisa realizar para concluir um projeto. Saiba mais sobre como começar com uma estrutura de divisão de trabalho.
Projetos Agile não usam estruturas de divisão de trabalho. Mas um backlog de produto Agile ou roteiro de produto geralmente serve a propósitos semelhantes.
O gerenciamento tradicional de projetos também pode incluir etapas e documentos para:
- Adotar o planejamento de gerenciamento de riscos
- Lidar com o planejamento de comunicação para membros da equipe, clientes e partes interessadas
- Implementar o planejamento de gerenciamento de mudanças
- Fazer o planejamento orçamentário
- Planejar os recursos e a equipe necessários
- Agendar todas as atividades do projeto
Quando as equipes usam o Agile para planejar e executar seus projetos de TI, elas realizam muitas das mesmas etapas acima, embora de maneira diferente e muitas vezes menos formal. Em vez disso, essas etapas às vezes fazem parte de sprints e iterações.
Aqui estão mais detalhes sobre como o Agile funciona – e se sua equipe está usando o Agile apropriadamente ou está apenas dizendo que está usando o Agile.
Exemplo de plano de projeto de TI
Baixar o exemplo de plano de projeto Agile de TI – Microsoft Excel
Este exemplo de modelo de plano de projeto Agile já vem completo para ajudá-lo a entender como planejar seu projeto de TI. O modelo de exemplo inclui entradas para sprints do Agile específicos, juntamente com recursos dentro desses sprints. Você também encontrará seções para membros da equipe responsáveis por cada item, datas de início e término planejadas e status atual.
Modelo de plano de projeto Agile
Baixar o modelo de plano de projeto Agile — Microsoft Excel
Você pode personalizar este modelo de plano de projeto Agile para planejar e monitorar seu projeto de TI Agile para seus próprios propósitos. O modelo inclui seções nas quais você pode adicionar tarefas, responsabilidades pelas tarefas, datas de início e término e status. A duração de cada tarefa será calculada automaticamente. Este modelo também apresenta um gráfico de Gantt (uma representação visual da linha do tempo do seu projeto), que se ajustará automaticamente quando você adicionar seus próprios dados à tabela.
Diferenças no planejamento para projetos de TI versus. projetos não relacionados a TI
Os projetos de TI são notáveis pela quantidade de ajustes e mudanças que acontecem desde o início do projeto até o fim. Muitos projetos que não são de TI têm muito menos mudanças. Assim, o planejamento de muitos projetos de TI requer abordagens diferentes.
Aqui estão duas diferenças principais:
- Projetos de TI são muito menos propensos a usar métodos tradicionais de gerenciamento de projetos: Os métodos tradicionais de projeto, como o Waterfall, são opções sólidas para alguns projetos de construção. Mudanças significativas nos planos são menos prováveis em tais projetos. Mas o desenvolvimento de software e outros projetos de tecnologia da informação encontram mudanças significativas por toda parte, o que os torna mais propensos a usar metodologias Agile ou Agile modificadas.
- Os orçamentos são mais propensos a mudar: Os orçamentos em projetos de TI podem mudar quando surgem obstáculos ou problemas imprevistos que exigem ajustes. Mas os orçamentos também podem mudar com o sucesso do projeto. Isso pode acontecer quando um novo produto de TI (desenvolvido ao longo de um projeto) é bem-sucedido e apreciado pelos clientes.
“A diferença entre não TI e TI é que, quando você termina um projeto de TI, é na verdade o começo de algo”, diz Shandil. “Quando você termina qualquer outro projeto, é o fim de algo.”
Quando as equipes de construção terminam um edifício, o orçamento da construção também está concluído. Mas quando os desenvolvedores de software terminam o software e os clientes o adoram, esses clientes continuamente sugerem mudanças para melhorá-lo. Isso significa que o orçamento para software e TI de sucesso cresce quando é bem-sucedido.
“Se você gastou US$ 2 milhões em software, gastará US$ 8 milhões antes de se aposentá-lo ou encerrá-lo”, explica Shandil.
Dicas para o planejamento de projetos de TI
Os especialistas recomendam formar e manter equipes de projeto. Você também deve determinar os documentos de planejamento que são necessários e os que não são, bem como mostrar o trabalho e o progresso.
Aqui estão algumas dicas de especialistas para o planejamento de projetos de TI:
- Manter equipes de projeto em andamento: Algumas organizações podem criar uma equipe personalizada para cada projeto específico. Mas Zucker diz que há vantagens em manter equipes contínuas compostas principalmente pelos mesmos membros – chamadas equipes persistentes – trabalhando em projetos sucessivos. Os membros da equipe conhecem uns aos outros e o que todos fazem de melhor, tornando o trabalho do projeto mais eficiente.
“Equipes persistentes podem ser usadas em qualquer ambiente: Agile ou tradicional”, diz Zucker. - Assegure-se de que seu objetivo seja o objetivo certo: Muitas vezes, os líderes da empresa ou do projeto anunciam uma meta para um projeto e imediatamente começam a fazer um planejamento para alcançá-la. Mas eles nem sempre analisam se esse é o objetivo certo ou se alcançá-lo será o resultado que eles desejam para a organização.
“Eu vi essa coisa toda acontecer muitas vezes”, compartilha Zucker. “Eles gastam 15 segundos no que querem alcançar e, em seguida, detalham imediatamente como implementar a coisa. Vamos ter certeza de que é isso que queremos fazer.” - É imprescindível definir o sucesso final corretamente: O sucesso em projetos de TI não depende do número de recursos que você adicionou a um software ou sistema digital, avisa Shandil. É sobre a satisfação do cliente.
“O melhor resultado são clientes satisfeitos, então normalmente estaríamos pensando: Quantos recursos você lançou este mês? Em vez disso, devemos pensar: Quantos clientes satisfeitos? Nós os deixamos satisfeitos com os recursos que lançamos este mês?” ele sugere perguntar. - Não se concentre muito em documentos escritos detalhados: A metodologia Agile é menos focada em exigir documentos escritos formais do que as metodologias mais tradicionais. Mas mesmo no Agile, é importante gerar alguma documentação sobre o plano básico de gerenciamento de projetos e o escopo. O que você não quer, no entanto, é perder tempo gerando documentação que imediatamente se torna obsoleta e retarda o progresso do projeto.
“A desvantagem é que isso o torna menos ágil, porque leva tempo para escrever essas coisas. Muitas vezes você está projetando no futuro. Talvez você nem saiba exatamente qual é o seu produto. Decida qual documentação é realmente necessária e depois edite. Essa também é uma competência – decidir o que é absolutamente necessário e o que não é necessário”, aconselha Sims. - Não se concentre muito no planejamento inicial: Esta dica está relacionada à documentação limitada. Não gaste muito tempo fazendo um planejamento detalhado antes de seu trabalho começar. Você vai querer definir alguns objetivos básicos e estrutura, é claro. Mas então coloque mãos à obra.
“Planeje agora para planejar depois”, diz Shandil. “E enquanto isso, aprenda um pouco mais.”
Isso significa que sua equipe pode trabalhar no produto ou projeto por um tempo limitado – durante um sprint de uma semana no Agile, por exemplo. “Os membros da equipe aprenderão mais durante essa semana de trabalho e poderão fazer planos rápidos para a próxima semana. E você apenas repete isso”, diz Shandil. “A principal diferença para nós é que você tem que entregar algo, porque senão você não está aprendendo nada.” - Entenda e use o conceito de produto mínimo viável: Um produto mínimo viável é um conceito que incentiva os desenvolvedores a colocar uma versão básica de um novo produto nas mãos dos usuários o mais rápido possível. Isso significa que não é o produto acabado, mas funciona em um nível básico e pode dar ao usuário uma ideia do conceito. Esse feedback inicial do usuário pode ajudá-lo a adicionar outros recursos e desenvolver ainda mais o produto.
“O melhor feedback é de usuários reais”, afirma Sim. - Estabeleça um contrato de trabalho sobre cultura de trabalho: No início de um projeto, Shandil incentiva os clientes a concordarem com um contrato de trabalho, que estabelece regras e princípios básicos sobre como as pessoas trabalharão juntas.
“Isso realmente faz com que as pessoas ajam mais como uma equipe e menos como um bando de colaboradores individuais”, diz ele. “Então, na verdade, criamos um livro de regras para a equipe.”
As regras podem incluir, por exemplo, que ficar em silêncio é concordar com tudo. “Dessa forma, as pessoas entendem que devem contribuir para as discussões e, se não o fizerem, não podem dizer depois que não concordaram”, explica Shandil.
- Assegure-se de que todos possam ver, monitorar e acompanhar facilmente o progresso de um projeto: Cada membro da equipe, cliente ou interessado deve poder ver facilmente o status e o progresso de um projeto. Os membros da equipe podem ver quanto trabalho resta e as pessoas externas ao projeto entendem o trabalho que está em andamento. Isso pode ajudar a garantir apoio político, financeiro e outros para este projeto e projetos futuros.
Shandil se lembra de um caso em que trabalhou em uma organização de saúde australiana que foi comprada. O CEO da empresa compradora visitou os escritórios e viu um grande quadro branco com projetos escritos nele no departamento de TI.
“Ela olha para este quadro e diz: ‘Uau, vocês trabalham muito. Eu não acho que meus caras em Sydney trabalham tanto.' Sabíamos que isso não era verdade. É só que eles não tornaram isso visível. Essa ideia é realmente fundamental para nós, porque ela pode passar pelos funcionários do conhecimento e um monte de coisas estão acontecendo em nossas cabeças. Ela não tem ideia, certo? Colocar isso em discussão e fazer com que as pessoas que não têm necessariamente uma formação técnica compreendam esse processo – isso é significativo.” - Pense em como você abordará a segurança cibernética: A segurança cibernética é importante para todos os projetos de TI. Para alguns projetos de TI, pode ser o componente mais importante a ser considerado no início do processo.
Isso significa que a segurança cibernética deve estar entre os primeiros riscos que uma equipe avalia e planeja. Sim diz que viu projetos em que os líderes de equipe avaliaram o que era preciso para garantir a segurança cibernética necessária para o produto. E esse orçamento de segurança cibernética acabou sendo cinco vezes o orçamento previsto para todo o projeto.
“Sabe, aquele (projeto) não faz mais sentido, certo?” ele diz. “É melhor descobrir isso muito logo no início do trabalho, não mais tarde.”
A taxa de falha para projetos de TI
A taxa de falha para projetos de TI é bastante alta. Desde 1994, o Standish Group publica seus relatórios CHAOS sobre o sucesso de projetos de TI. Em seu relatório de 2015, descobriu que 36% dos projetos de TI foram concluídos com sucesso em 2015. Outros 46% foram “questionados”, o que significa que o projeto estava concluído e operacional, mas estava acima do orçamento, concluído após o prazo ou oferecia menos recursos do que o planejado originalmente. Outros 19% dos projetos falharam completamente e foram cancelados.
O relatório “Pulse of the Profession” de 2021 do Project Management Institute encontrou algumas melhorias no sucesso dos projetos de TI em relação aos anos anteriores. Ainda assim, os números mostraram muito espaço para mais melhorias. O relatório constatou que 64% dos projetos de TI foram concluídos dentro do orçamento e 59% foram concluídos no prazo. O relatório descobriu que 33% dos projetos de TI falharam e perderam seu orçamento.
Por que os projetos de TI falham
Especialistas dizem que os projetos de TI falham por vários motivos. Os motivos incluem objetivos pouco claros, comunicação deficiente entre os líderes da equipe do projeto e as partes interessadas e feedback insuficiente do usuário no início do processo.
Aqui estão os detalhes sobre problemas específicos que causam problemas:
- Líderes de projeto e membros da equipe fora de sincronia entre si e com as partes interessadas: Em projetos que falham, os líderes de projeto e os membros da equipe não se comunicam com frequência suficiente com clientes e partes interessadas. Quando eles se comunicam, eles o fazem mal, e cada lado tem uma ideia diferente das metas e objetivos do projeto.
- Responsabilidade confusa: Os líderes e membros da equipe também podem ficar confusos sobre quem é responsável por quais tarefas e funções gerais no projeto.
- Requisitos pouco claros: Um fator importante em projetos de TI que falham é a falta de clareza em relação aos requisitos do produto no centro do projeto, logo no início.
- Muita segmentação de trabalho e repasses de má qualidade: Boas equipes de projeto incluem membros de vários departamentos da empresa que podem trabalhar juntos e garantir que eles e suas equipes maiores não trabalhem em silos. Esses silos podem causar grandes problemas envolvendo tarefas ao repassar um projeto de um departamentos para outro.
“A maneira antiga de fazer isso é quase como uma coisa da Guerra Fria”, diz Shandil. “Alguém vai até um banco de parque, coloca algo embaixo dele e depois vai embora. Então alguém vem e pega. Sabemos que isso não funciona.”
Os membros da equipe de diferentes departamentos precisam trabalhar juntos em equipes multifuncionais, aconselha Shandil. “Essa ideia de ter uma equipe multifuncional dedicada significa que não há repasses.” - Demorando demais para realizar o planejamento preliminar e trabalhar no produto: As empresas geralmente demoram muito para planejar e realizar o trabalho preliminar no produto central. Eles devem realizar algum planejamento e trabalho preliminares, mas colocar uma versão do produto nas mãos dos usuários o mais rápido possível.
O longo planejamento e desenvolvimento vêm com outro perigo: o mercado terá superado o produto que eles estavam planejando construir. “Se você levar um ano para lançar qualquer coisa, isso já é muito tempo”, afirma Sim. “E a tecnologia pode superar tudo o que você está tentando fazer.”
Simplifique o planejamento de projetos de TI com o Smartsheet
Capacite seu pessoal para ir além com uma plataforma flexível desenvolvida para atender às necessidades da sua equipe e se adaptar conforme essas necessidades mudam. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período de tempo. Experimente o Smartsheet gratuitamente hoje mesmo.