introdução
os projetos costumam ser os meios para operacionalizar planos estratégicos de uma organização. Estão previstos projetos para desenvolver produtos e serviços e para obter eficiência operacional. Os negócios estão se tornando cada vez mais projetizados e os gastos globais em projetos estão na ordem de muitos bilhões de dólares anualmente (Williams, 2005). As razões são óbvias. Os projetos oferecem uma oportunidade para empregar práticas de gerenciamento de projetos que promovam o uso eficiente e eficaz dos recursos. No entanto, apesar dos avanços na disciplina e profissão de gerenciamento de projetos, a experiência comum sugere que muitos projetos falham (Williams, 2005), o que ressalta a importância e a necessidade de melhorar os processos e o desempenho de gerenciamento de projetos.Em geral, as organizações se esforçam para implementar as melhores práticas de gerenciamento de projetos tradicionais-com base nos padrões do PMI—para atingir os objetivos do projeto e atender às expectativas do cliente. No entanto, nem todos os processos e práticas recomendados do corpo de Conhecimento de gerenciamento de projetos (Guia PMBOK®) podem ser relevantes para cada projeto. Muitas vezes, uma abordagem seletiva faz sentido na adoção de processos e práticas de gerenciamento de projetos para atender às necessidades específicas do projeto com base em seu tamanho, tipo, complexidade e no setor em que o projeto é realizado. Essa necessidade de uma abordagem diferente para gerenciar projetos de TI está bem documentada na literatura de gerenciamento de projetos.Os projetos de desenvolvimento de Software muitas vezes enfrentam desafios conflitantes de desenvolver produtos de software em um ritmo acelerado, enquanto os desenvolvem com uma robustez para torná-los confiáveis (Boehm, 2002). Os projetos de TI, com o objetivo de acompanhar os desenvolvimentos tecnológicos em rápida mudança, muitas vezes passam por mudanças de escopo durante as etapas de planejamento e implementação. Consequentemente, os projetos de TI têm desafios diferentes dos projetos tradicionais. Vários ajustes e modificações nas práticas tradicionais de gerenciamento de projetos são desenvolvidos e praticados para projetos de TI, introduzindo assim novas metodologias de gerenciamento de projetos, como Gerenciamento Ágil de projetos.
A metodologia Ágil de gerenciamento de projetos—com sua maior adaptabilidade ao escopo em constante mudança-usa planejamento iterativo ou em fases e integração contínua. O princípio fundamental é manter o escopo do projeto suave. A metodologia promove a colaboração e resulta em maior satisfação do cliente. No entanto, o agile não é uma solução completa para o desenvolvimento de software em ritmo acelerado, atendendo às demandas de robustez e confiabilidade dos clientes. Nesse contexto, Boehm (2002) recomendou uma combinação de gerenciamento de projetos tradicional e Metodologia Ágil de desenvolvimento de software viável e preferível. Uma abordagem complementar seria desenvolver uma abordagem baseada em riscos que seja adaptada para reter os benefícios de métodos ágeis e orientados a planos e, ao mesmo tempo, mitigar muitos de seus pontos fracos (Boehm & Turner, 2003).
este trabalho de pesquisa visa examinar as proposições acima (Boehm, 2002; Boehm & Turner, 2003) de uma abordagem combinada para gerenciar projetos de consultoria de TI, que são diferentes dos projetos de TI. Os projetos de consultoria de TI são concebidos para gerenciar e fornecer suporte a projetos de TI. Eles são frequentemente iniciados no setor governamental. Projetos de consultoria de TI não são projetos de desenvolvimento de software; em vez disso, eles fornecem suporte a projetos de TI.
neste estudo, pretendemos desenvolver uma compreensão de como as práticas ágeis de gerenciamento de projetos são relevantes para projetos de consultoria de TI. Os objetivos do estudo são identificar os benefícios do uso do Gerenciamento Ágil de Projetos, sua adequação e quais aspectos do gerenciamento tradicional de projetos podem ser combinados com o Gerenciamento Ágil de projetos para projetos de consultoria de TI para melhorar o desempenho do projeto. Na próxima seção, Usando uma extensa revisão de Literatura da Metodologia Ágil de gerenciamento de projetos, identificamos características importantes do método ágil e sua abordagem única para gerenciar projetos em comparação com o gerenciamento de projetos tradicional. A revisão de Literatura tem ajudado a desenvolver uma compreensão dos principais conceitos e benefícios do uso do desenvolvimento Ágil de software. Além disso, com base nos achados de revisão de literatura, desenvolvemos e apresentamos um método de pesquisa usando um questionário estruturado para desenvolver uma compreensão dos projetos de consultoria de TI. A análise e a discussão dos dados, apresentadas posteriormente, fornecem insights e descobertas importantes do estudo. Concluímos o artigo com nossos resultados de pesquisa e recomendações para projetos de consultoria de TI.
revisão de Literatura
práticas tradicionais de gerenciamento de projetos, que são impulsionadas por planejamento abrangente, podem ser usadas quando as especificações do projeto são claramente definidas. Por outro lado, quando as especificações estão sujeitas a mudanças frequentes durante a vida do projeto, a abordagem tradicional para gerenciar projetos pode não funcionar de forma eficiente. Os projetos de desenvolvimento de Software geralmente são concebidos com especificações mínimas, causando mudanças frequentes nessas especificações durante a implementação do projeto. Além disso, as durações de desenvolvimento de projetos de software são curtas. Os métodos ágeis, em comparação com as técnicas tradicionais de gerenciamento de projetos, são adequados para projetos de desenvolvimento de software devido à curta duração desses projetos para desenvolvimento (Hanakawa & Okura, 2004).
em geral, vários métodos de desenvolvimento de software, como o agile project management, prometem maior satisfação do Cliente, menores taxas de defeitos, tempos de desenvolvimento mais rápidos e servem como uma solução para os requisitos de projeto em rápida mudança (Boehm & Turner, 2003). Em contraste com o Gerenciamento Ágil de Projetos, um modelo stage-gate usa um processo de trabalho da ideia de conceito para um produto que é entregue em última análise. Este modelo desenvolve fases do ciclo de vida do gerenciamento de projetos com base em diferentes estágios de desenvolvimento de produtos para gerenciar projetos. Uma distinção importante entre um modelo stage-gate e o Gerenciamento Ágil de projetos é que o primeiro tenta minimizar as mudanças de requisitos para que o produto seja concluído a tempo (Karistrom & Runeson, 2005). Outro método para desenvolver software é o SCRUM, que é um conjunto de princípios de gerenciamento de projetos que empregam pequenas equipes multifuncionais e autogerenciadas (Schatz & Abdelshafi, 2005). O SCRUM exige que cada membro da equipe e product owner trabalhem juntos no início de cada item de desenvolvimento e a metodologia atua como um invólucro em torno dos processos de desenvolvimento existentes. Portanto, Schatz e Abdelshafi argumentaram que o SCRUM não terá um plano básico para medir o sucesso do projeto. No entanto, o Gerenciamento Ágil de projetos é considerado para este estudo devido à sua maior flexibilidade e adaptabilidade aos projetos de desenvolvimento de software.Além dos benefícios discutidos acima, a metodologia ágil é aplicável a ambientes turbulentos e em constante mudança (Highsmith & Cockburn, 2001). Além disso, o método ágil enfatiza a adaptabilidade ao mercado, tecnologia e processo (Mellor, 2005). A metodologia ágil é uma abordagem que se concentrará em recursos importantes primeiro e, como resultado, procurará feedback inicial sobre os recursos (Karistrom & Runeson, 2005). Uma vez identificados recursos importantes, o gerente de projeto garantirá que não haja atrasos. Karistrom e Runeson indicaram que o processo ágil evitaria o acúmulo de recursos, planos fixos e suporte a planos de longo prazo.No entanto, a metodologia ágil não é adequada para todos os projetos de desenvolvimento de software. Citando Scott Ambler, o desenvolvedor do método ágil, Boehm (2002) recomendou a metodologia tradicional de gerenciamento de projetos orientada a planos para software de garantia, como sistemas críticos à vida.
o método ágil, devido ao seu exigente ambiente de projeto caracterizado pelo caos e incerteza, precisa de equipes de projeto compostas por pessoas talentosas para atender às necessidades e demandas desafiadoras. Citando um estudo de pesquisa de Constantine (2001), Boehm (2002) sugeriu que os métodos ágeis exigem pessoas altamente capazes. Além disso, o agile não é adequado para equipes maiores (Highsmith & Cockburn, 2001), pois requer um trabalho em equipe fortemente coordenado para ter sucesso, e equipes com mais de 15 ou 20 Desenvolvedores aumentam a dificuldade de gerenciar o projeto (Constantine, 2001).
é óbvio que o método ágil emprega equipes coerentes (Karistrom & Runeson, 2005). Karistrom e Runeson identificaram recursos ágeis adicionais, como tarefas pequenas e gerenciáveis, integração contínua e testes automáticos. Consequentemente, as equipes de projetos ágeis são caracterizadas por uma boa comunicação interna, maior qualidade e uma sensação de estar no controle (Karistrom & Runeson). Eles, no entanto, prevêem potencial isolamento para a equipe ágil.
em termos de comunicação, gerenciamento de progresso baseado em documentos e controle de qualidade, uma prática comum no gerenciamento tradicional de projetos não corresponde ao método ágil de desenvolvimento de software (Hanakawa & Okura, 2004). A interação presencial para o realinhamento contínuo dos objetivos de desenvolvimento é geralmente preferida em metodologias ágeis (Melnik & Mauer, 2004). Destacando a diferença entre métodos tradicionais e ágeis, Melnik e Mauer sugeriram que a transferência curta de conhecimento e a comunicação direta e a colaboração são preferidas no desenvolvimento de software, em contraste com as práticas tradicionais de gerenciamento de projetos, onde são utilizadas longas cadeias de transferência de conhecimento, que muitas vezes são suscetíveis a distorção e perda de informações.
uma das diferenças importantes entre as práticas tradicionais de gerenciamento de projetos baseadas em planos e métodos ágeis é que os métodos ágeis capturam a agilidade do conhecimento tácito da equipe do projeto em vez do conhecimento explícito, frequentemente usado na forma de documentos e planos em gerenciamento de projetos tradicional (Boehm, 2002).
outra diferença é a quantidade e o tipo de documentação criada para projetos. O gerenciamento tradicional de projetos orientado a planos enfatiza o planejamento detalhado, o monitoramento e o controle de documentos. Racionalizações de Design, documentos que expressam razões e justificativas, são criados usando um procedimento altamente automatizado e essas justificativas de design servem como documentação ágil (Sauer, 2003).Coram e Bohner (2005) identificaram características comuns do método ágil: colaboração, equipes pequenas, cronogramas de lançamento curtos, time boxing e testes constantes. O gerente de projeto é responsável por garantir um ambiente altamente colaborativo. Para isso, o método ágil incentiva pequenas equipes e algumas sub-equipes por projeto a promover a colaboração. Como consequência, o método ágil provavelmente exigirá menos processo e planejamento para coordenar as atividades da equipe. O método ágil também usa cronogramas de lançamento curtos, que podem variar de duas semanas a seis meses. Time boxing é um conceito que impõe duração fixa para o lançamento de entregas do projeto, o que ajuda a reduzir o revestimento de ouro e a fluência do escopo. Testes constantes garantem a qualidade e integração do produto. Além disso, Coram e Bohner sugeriram que os gerentes de projeto devem acompanhar o progresso e tomar decisões de negócios com ênfase em responder à mudança, em vez de seguir um plano específico.
o Time boxing leva a um planejamento imprevisível por best guess e datas fixas podem trazer surpresas inesperadas durante a fase de desenvolvimento (Patton, 2003). Outro resultado desse processo iterativo de planejamento de projetos é que o método ágil não pode monitorar o progresso com base na porcentagem de conclusão (Patton, 2003).
O envolvimento de pequenas sub-equipes no planejamento resultará em motivado engenheiros de desenvolvimento de software; técnicas de questões são levantadas no início do projeto e não vai ser pouca resistência na implementação (Karistrom & Runeson, 2005). Além disso, definir o escopo do projeto com uma abordagem ágil resultaria em redução de custos (Mcgovern, 2002). O método ágil usa planejamento baseado em requisitos e também nos permitirá controlar o escopo (McGovern).
Usando de todas as referências e discussões até o momento e outros (Pouco Greene, Phillips, Pilger & Poldervaart, 2004; Little, 2005; Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Ilieva, Ivanov, & Stefanova, 2004; Lindvall, 2004), a Tabela 1 fornece um resumo da comparação entre o tradicional e ágil práticas de gestão de projetos.
Quadro 1: Comparação entre métodos Ágeis e Tradicionais de Gestão de projetos
| fase de Projeto | Tradicional | Agile |
| Iniciação |
|
|
| Planejamento |
|
|
| Execution |
|
|
| Monitoramento e Controle de |
|
|
| Encerramento |
|
|
Resumo da Revisão de Literatura
Ágeis de gerenciamento de projetos a metodologia é comumente usado para projetos de desenvolvimento de software. Tem maior adaptabilidade ao escopo em constante mudança. Como consequência, o Gerenciamento Ágil de projetos usa planejamento iterativo ou em fases e integração contínua ao longo da vida útil do projeto. O princípio fundamental no Gerenciamento Ágil de projetos é manter o escopo do projeto suave. O método ágil de gerenciamento de projetos é diferente de um método tradicional de gerenciamento de projetos, atribuindo importância a fatores tradicionalmente considerados sem importância. Agile atribui importância relativamente maior para:
- Indivíduos e interações sobre processos e ferramentas
- execução do Projeto mais abrangente de documentação
- colaboração com o Cliente sobre a negociação de contrato
- Resposta para alterar mais de um plano de projeto
O método ágil enfatiza a flexibilidade para atender às necessidades do projeto. Além disso, ele depende do feedback do cliente para iniciar alterações em um plano de projeto. A metodologia usa a abordagem de identificar os usuários finais apropriados e seus objetivos para formular entregas de projetos e atender às necessidades de desempenho dos processos de negócios. As vantagens de usar o método ágil incluem maior satisfação do Cliente, menores taxas de defeitos e tempos de desenvolvimento mais rápidos. Além disso, o método ágil é uma resposta a requisitos em rápida mudança, pois usa o feedback inicial sobre os recursos de tecnologia dos entregáveis do projeto. O método ágil garante que os requisitos não sejam preenchidos. Os principais recursos do método ágil são a comunicação eficaz dentro e fora da equipe do projeto e a flexibilidade demonstrada na adição de mais requisitos.
esses benefícios ajudariam as organizações a fornecer um melhor atendimento ao cliente. Além disso, eles são relevantes na economia atual, onde a globalização e uma filosofia de marketing livre estão afetando as percepções dos clientes em aumentar as expectativas para entregar produtos e/ou serviços de forma mais rápida, barata e melhor.
no entanto, o método ágil não é isento de deficiências, como pode ser visto na Tabela 1. A mudança frequente do escopo leva a dificuldades no monitoramento do progresso do projeto. Além disso, não é fácil capturar conhecimento tácito na forma de lições aprendidas. Controle de mudanças de escopo, documentação, plano abrangente, gerenciamento de qualidade e gerenciamento de riscos são benefícios importantes do gerenciamento de projetos tradicional dos quais podemos ser privados ao empregar o método ágil.
metodologia de pesquisa
utilizamos entrevistas pessoais e questionários para coletar os dados. Foi desenvolvido um questionário estruturado composto por duas seções. A primeira seção foi projetada para capturar detalhes sobre o projeto e suas características. Esta seção consiste em 13 perguntas, que estão relacionadas à demografia do projeto e às práticas de gerenciamento de projetos. Eles foram apresentados aos participantes do estudo com a opção de fornecer respostas abertas quando necessário.
a segunda seção se concentrou nas declarações de práticas de gerenciamento de projetos, e os participantes foram solicitados a responder a essas declarações em escala de cinco pontos com 1 denotando “discordo totalmente” e 5 denotando “concordo totalmente.”As declarações a seguir foram usadas abordando importantes princípios comuns das práticas de gerenciamento de projetos, além de servir para contrastar as práticas tradicionais e ágeis de gerenciamento de projetos.
- os critérios para medir o sucesso do projeto são baseados nos objetivos e metas do projeto.
- o projeto é impulsionado por requisitos.
- o projeto é adaptável à mudança.
- na sua opinião, os esforços de gerenciamento de projetos alcançaram resultados esperados
- interações presenciais e cadeias de comunicação mais curtas recebem mais importância do que processos e ferramentas.
- o foco da equipe está na execução do projeto em uma documentação abrangente.
- a colaboração do cliente sobre a negociação de contratos funciona melhor para sua equipe.
- o projeto tem um escopo de projeto bem definido.
- as práticas de gerenciamento de projetos seguem o ciclo de vida do projeto Guia PMBOK®.
- o planejamento iterativo ou em fases do projeto é seguido para o projeto.
- o projeto possui requisitos de documentação, como adesão a padrões como ISO9000, OMB 300.
- os procedimentos de teste de aceitação do Usuário (UAT) são seguidos ao longo do projeto.
- o gerente de projeto tem o poder de tomar decisões relacionadas ao Projeto sem a intervenção do cliente.
as respostas a essas afirmações são analisadas em conjunto com as perguntas apropriadas do primeiro conjunto de 13 perguntas. Juntas, as respostas a ambas as seções forneceram uma compreensão detalhada do projeto para uma análise significativa.
resultados do estudo
o questionário foi estruturado para capturar dados de 20 projetos de consultoria de TI, que estavam em andamento no momento da pesquisa. Dos projetos, 65% são projetos do tipo contrato de tempo e material e os restantes são do tipo preço fixo firme (FFP). Entre os projetos de tempo e materiais, 55% têm uma duração de projeto de mais de dois anos.
A maioria das equipes de projeto é pequena: apenas 15% têm 10 ou mais membros. No que diz respeito à comunicação entre os membros da equipe do projeto, 60% dos entrevistados usaram apenas comunicação formal para as necessidades do projeto; 30% usavam comunicação formal e informal, e os 10% restantes dependiam apenas de métodos informais.
um em cada dois entrevistados indicou que seus projetos usaram um plano de projeto. Em uma questão relacionada, dos projetos que não tinham um plano de projeto, 80% também não usavam planejamento iterativo.
A mudança de escopo é um aspecto importante deste estudo. Dos projetos, 70% experimentaram mudanças de escopo pelo menos uma vez. Dos que experimentaram mudanças no escopo do projeto, 60% experimentaram mais de duas vezes. Enquanto o cliente decide a mudança de escopo, o consultor—com o consentimento do cliente—pode incluir o plano de controle de qualidade no plano de gerenciamento de projetos. Quando perguntados se eles têm um plano de controle de qualidade para seu projeto, 65% dos entrevistados indicaram que não usaram um plano de controle de qualidade.
resultados discussão e análise
os resultados da pesquisa foram analisados examinando cuidadosamente qualquer inter-relação entre uma questão e todas as outras questões primeiro para validar os resultados e segundo, para desenvolver estratégias de gestão eficazes. Além disso, esses resultados foram analisados com o objetivo de examinar quais práticas ágeis e tradicionais de gerenciamento de projetos podem ser usadas em combinação para desenvolver uma abordagem robusta de gerenciamento de projetos para projetos de consultoria de TI.
critérios de sucesso do projeto com base em seus objetivos e metas
um projeto é considerado bem-sucedido quando atende a seus objetivos e metas. Apenas 60% dos entrevistados concordaram com a Declaração: “os critérios para medir o sucesso do projeto são baseados nos objetivos e metas do projeto.”Cerca de 30% dos entrevistados discordaram. Uma análise mais aprofundada mostrou que a razão para discordar foi que esses projetos estavam passando por constantes mudanças nas condições e requisitos, ou o cliente não estava claro sobre o projeto. Em última análise, esses projetos estavam passando por mudanças frequentes no escopo. Em um caso particular, as metas e objetivos do projeto mudaram.É interessante notar que não há associação entre o fato de que os critérios de sucesso de um projeto são derivados de seus objetivos e mudança de escopo, tipo de projeto e a existência de um plano de projeto. Em outras palavras, derivar critérios de projeto do plano estratégico da organização não tem relação com a mudança de escopo e se o projeto tem um plano.
requisitos do projeto
normalmente, um plano de projeto detalhado é desenvolvido após os requisitos do patrocinador do projeto serem claramente identificados. O desenvolvimento do plano de projeto e sua execução, em princípio, devem ser impulsionados por esses requisitos. Portanto, seria de se esperar que os gerentes de projeto concordassem com a afirmação: “o projeto é impulsionado por requisitos.”Os resultados do estudo mostram que apenas 60% dos entrevistados disseram que seus projetos são movidos por requisitos. Cerca de 20% dos entrevistados que discordaram da declaração indicaram que seus projetos são executados sem o uso de um plano de projeto.
cerca de 20% dos entrevistados que foram neutros em resposta a esta afirmação são os gerentes de projeto que não experimentaram nenhuma mudança de escopo em seus projetos. Todos os outros entrevistados, aqueles que concordaram ou discordaram da declaração, experimentaram mudanças de escopo pelo menos uma vez em seus projetos atuais.
em geral, se um projeto não for implementado de acordo com seu plano, podemos assumir que os requisitos não são identificados ou os requisitos do projeto devem mudar durante sua execução. Neste estudo, no entanto, não podemos estabelecer tal associação entre “implementar o projeto sem usar o plano do projeto” e “o projeto não é impulsionado por requisitos”, porque apenas 50% dos que concordaram com a segunda declaração também gerenciaram projetos sem usar um plano.
adaptabilidade à mudança
dezoito dos 20 projetos responderam às mudanças no projeto com sucesso. A adaptabilidade à mudança é considerada uma característica primária para um projeto ser candidato ao uso da Metodologia Ágil de gerenciamento de projetos. Projetos de consultoria de TI representados neste estudo demonstraram que eles têm adaptabilidade para lidar com a mudança de escopo.
os esforços de gerenciamento de projetos alcançaram resultados esperados
os resultados sugerem que o cliente está satisfeito com o resultado na maioria dos projetos (70%). No entanto, essas respostas não foram associadas a respostas a outras questões importantes da pesquisa sobre o progresso do projeto e o produto desenvolvido a partir da perspectiva do gerente de projeto. As razões são óbvias. Os projetos ainda estavam passando por excessos de tempo e custo. Embora o resultado final na entrega do produto de software seja satisfatório, os processos de gerenciamento de projetos não foram executados com sucesso. A inferência pode ser que a adoção de práticas tradicionais de gerenciamento de projetos, como desenvolvimento de Marcos, monitoramento e controle, teria ajudado a gerenciar o projeto com sucesso.
a importância da comunicação presencial versus processos
A comunicação é a chave para entender papéis, responsabilidades, políticas e procedimentos relacionados a projetos e incentivar a colaboração. Em última análise, a comunicação leva a uma equipe de projeto coesa e incentiva os membros da equipe a colaborar e participar da tomada de decisões. Sete em cada dez gerentes de projeto que participaram do estudo concordaram que interações face a face e cadeias de comunicação mais curtas receberam mais importância do que processos e ferramentas.
os resultados mostram uma forte associação entre a importância da comunicação presencial e os meios de comunicação entre os membros da equipe do projeto. Aqueles que discordaram que a comunicação face a face é mais importante do que os processos do projeto usaram a comunicação informal entre os membros da equipe do projeto, enquanto aqueles que consideraram a comunicação face a face mais importante usaram a comunicação formal e informal.
o foco na execução do projeto sobre a documentação
A documentação do projeto é frequentemente negligenciada e, consequentemente, as organizações são privadas de lições importantes aprendidas no planejamento e execução do projeto. Considerando que todos os projetos representados neste estudo são projetos do governo federal, é interessante notar que 70% de responder gerentes de projeto concordaram que suas equipes focadas na execução do projeto, em comparação à criação de uma documentação abrangente. Em alguns casos em que os gerentes de projeto consideraram que a documentação é mais importante do que a execução do projeto, uma investigação mais aprofundada revelou que o cliente estava indeciso sobre o projeto em todos esses casos.
a colaboração do cliente sobre negociação de contratos
A negociação de contratos é uma característica essencial dos projetos externos. Durante a negociação, ambas as partes se concentrariam em proteger seus interesses próprios. A negociação do contrato pode ocorrer em diferentes etapas do projeto. É desejável lidar com essas questões por meio da colaboração, especificamente durante a implementação do projeto; caso contrário, isso levará a problemas como a extensão do contrato. Dado que todos os projetos representados neste estudo são contratos, é animador notar que mais da metade dos gerentes de projeto respondentes (60%) consideram a colaboração do cliente mais importante do que a negociação de contratos. Eles sugeriram que a colaboração funciona melhor para as equipes de projeto.
onde houve discordância, implicando que a colaboração não é tão importante quanto a negociação, dois fatos interessantes foram associados a esses projetos. Todos os outros projetos usaram o contato direto como meio de comunicação com as partes interessadas do projeto, mas esses projetos usaram a comunicação em cadeia de comando e o cliente também foi indeciso sobre o projeto. Ambos os fatores implicam condições difíceis de colaboração.
projeto e um escopo de projeto bem definido
os projetos geralmente estão associados a incertezas e fatores desconhecidos, o que leva à ambiguidade. Como conseqüência, escopo e especificações detalhados não podem ser desenvolvidos durante a fase inicial do projeto. O escopo do projeto muda continuamente ao longo do projeto. Às vezes, os objetivos originais do projeto também podem mudar. Dos projetos pesquisados, 40% têm escopo bem definido, enquanto outros 45% não.
no entanto, 80% dos projetos experimentaram mudanças de escopo pelo menos uma vez, o que valida os argumentos apresentados anteriormente.
práticas de gerenciamento de Projetos e o ciclo de vida do projeto Guia PMBOK®
O Guia PMBOK ® desenvolveu um elaborado processo de ciclo de vida de gerenciamento de projetos; é exaustivo e abrangente. No entanto, não é necessário que todos os processos do ciclo de vida de gerenciamento de projetos do Guia PMBOK® sejam aplicados a todos os projetos. Sua adoção deve ser específica do projeto. Como esperado, 45% dos gerentes de projeto seguiram as práticas de gerenciamento de projetos do ciclo de vida do projeto Guia PMBOK®, e outros 45% não.
planejamento de projeto iterativo ou em fases
definição de escopo e plano de gerenciamento de projetos fazem parte do plano de projeto. Como discutido anteriormente, o desenvolvimento detalhado do escopo e das especificações não pode ser desenvolvido no início do projeto. Consequentemente, o escopo do projeto muda continuamente ao longo do projeto, o que sublinha a importância do planejamento iterativo ou faseado do projeto, uma característica importante do método ágil. Quando perguntados se o planejamento de projeto iterativo ou em fases é seguido para o projeto ou não, metade dos entrevistados indicou sim e apenas 15% não seguiu o planejamento iterativo do projeto. É interessante notar que todos aqueles que discordaram da prática do planejamento iterativo do projeto não tinham um plano de projeto em primeiro lugar.
documentação e adesão aos padrões
A documentação do projeto serve como referência para análise de dados históricos e ajuda as organizações a melhorar continuamente os processos de gerenciamento de projetos e desenvolver padrões. A documentação também ajudará a identificar as lições aprendidas e a modificar os sistemas de gerenciamento de projetos que levarão à maturidade do gerenciamento de projetos. OMB300 e ISO9000 servem como guias na concepção de sistemas de documentação do projeto. Especificamente, muitos projetos governamentais são obrigados a aderir às diretrizes OMB300. Dos entrevistados, 80% disseram que os projetos de TI que estavam gerenciando tinham requisitos de documentação, como adesão a padrões como ISO9000 e OMB300. No entanto, esses requisitos para os projetos de consultoria de TI são aplicáveis de forma limitada.
Procedimentos de teste de aceitação do Usuário
a satisfação do cliente é a principal medida de qualidade e sucesso para itens entregues pelo projeto. Portanto, os procedimentos de teste de aceitação do usuário são considerados importantes. Mesmo no caso de entregas de projetos menos tangíveis, como serviço, a medida subjacente do sucesso do projeto é a satisfação do cliente. No entanto, é subjetivo. Apenas 30% dos entrevistados disseram que seguiram os procedimentos de teste de aceitação do usuário ao longo do projeto, e 45% dos entrevistados não.
empoderamento para tomar decisões relacionadas ao Projeto
em geral, os gerentes de projeto devem ter liberdade para tomar decisões relacionadas ao Projeto sem intervenção do cliente, quando essas decisões não têm grande impacto no escopo do projeto ou nas entregas do projeto. Apenas 15% concordaram que o gerente de projeto tem o poder de tomar decisões relacionadas ao Projeto sem a intervenção do cliente. Cerca de 40% permaneceram neutros, e os 45% restantes disseram que o gerente de projeto não tinha esse poder. Dado que esses projetos são projetos externos e governamentais, esses resultados fazem sentido.
conclusão
nossos resultados do estudo mostram que a maioria dos projetos é impulsionada por requisitos. Quase todos os projetos representados neste estudo demonstraram que são adaptáveis à mudança. A comunicação Informal é considerada mais importante do que processos e sistemas formais. Considerando que os projetos do estudo estão relacionados ao trabalho do governo, os resultados mostram a equipe do projeto focada na execução do projeto sobre a documentação abrangente. Além disso, a colaboração do cliente sobre a negociação de contratos funciona melhor para as equipes de projeto. A mudança frequente do escopo do projeto significa a importância do planejamento de projetos iterativo ou em fases; uma característica importante do Gerenciamento Ágil de projetos. Dado que todos os projetos de consultoria de TI representados neste estudo são contratos, os resultados do estudo incentivam formalmente a adoção de metodologia ágil para projetos de consultoria de TI e a combinação deles com práticas tradicionais de gerenciamento de projetos, como desenvolvimento e monitoramento de Marcos orientados a planos, procedimentos de aceitação de usuários e práticas de gerenciamento de qualidade.
a adequação do método ágil para projetos é obrigação contratual relacionada a documentos relativos ao planejamento, monitoramento e controle do projeto. Projetos associados ao governo federal geralmente têm requisitos de documentação significativos, como adesão a padrões como ISO9000 e OMB300; devemos ter cautela na modificação do método ágil para tais projetos.O desafio é manter a agilidade, a resposta rápida à mudança, planos flexíveis e simples, integração contínua e outros benefícios do método ágil, incorporando alguns dos processos abrangentes das práticas tradicionais de gerenciamento de projetos.