IV. ESTUDO DE CASO – PROJETO XYZ
2. Problemas Identificados
O projeto XYZ apresentou os problemas representados através da matriz “fases X áreas de conhecimento” proposta pelo PMBoK. Através desta matriz é possível perceber que os mesmos ocorreram envolvendo a maioria das áreas de conhecimento ao longo do projeto.
Para este estudo de caso, serão analisados os principais problemas que desencadearam grande parte dos demais.
1º Problema: [ RIS - INI 1 ] – Análise Crítica
“Por imposição da diretoria da empresa prestadora de serviço, foi assumido o risco da falta de experiência da equipe do projeto.”
A empresa de desenvolvimento de software contratada assumiu um risco elevado, sem avaliar adequadamente as conseqüências, ao formar uma equipe com pouca experiência para executar o projeto. A equipe tinha a seguinte composição:
Figura 6 – Estrutura Equipe Projeto Fonte: Autor, 2007
Em relação aos processos definidos pelo PMBoK:
Figura 7 – Processos de Riscos seguidos ou não pelo projeto Fonte: Adaptado de PMBoK, 2004
O planejamento, identificação e análise qualitativa dos riscos foram realizados. A análise quantitativa não foi realizada por não ser praticado pela empresa.
O planejamento de resposta ao risco identificado não foi realizado mas o líder do projeto deveria ter definido uma estratégia de resposta por se tratar de um risco com alto grau de impacto nos objetivos do projeto e alta probabilidade de ocorrência. Neste caso, a resposta mais adequada seria a mitigação, já que ações antecipadas seriam mais efetivas do que tentar reparar as conseqüências no prazo e qualidade (por exemplo) depois que o risco se concretizasse.
Uma possibilidade para mitigação deste risco seria a previsão de mais um recurso na equipe, caso o analista sênior previsto para o projeto não tivesse disponibilidade para dar apoio aos menos experientes.
Processos de Gerenciamento de Riscos
•
Planejamento do gerenciamento de riscos•
Identificação de riscos•
Análise Qualitativa de riscos•
Análise Quantitativa de riscos•
Planejamento de respostas a riscos•
Monitoramento e controle de riscosSênior
Pleno
O monitoramento e controle do risco também não foi realizado já que o líder do projeto não acompanhou o desempenho dos colaboradores de sua equipe com pouca experiência. O líder utilizou o estilo de liderança Liberal ou Delegador (S4) e, conforme já abordamos no capítulo “Liderança”, o mais adequado seria o estilo Treinador (S2), ainda adotando um comportamento direcionador, que é o indicado para o perfil M2 (não têm capacidade, mas têm vontade) destes colaboradores.
Conseqüências decorrentes dos erros cometidos pelo líder e descritos anteriormente (agrupados por áreas de conhecimento e mapeados na matriz “fases X áreas de conhecimento” – figura 12) foram:
- Recursos Humanos: Dificuldade para a realização das atividades do projeto - Tempo: O prazo de implementação da maioria das atividades não foi cumprido. - Tempo: Atraso na entrega do projeto.
- Custo: O custo real do projeto ultrapassou o estimado. - Qualidade: Reprovação do produto entregue.
2º Problema: [TEM - EXE 3] – Análise Crítica
“O prazo/esforço definido para as atividades não estava de acordo com as características das mesmas”
O líder agiu de maneira equivocada pois dividiu igualmente o tempo total de duração do projeto pelo número de atividades existentes, não levando em consideração a complexidade da atividade e nem o perfil (experiência e qualificação técnica) do colaborador alocado para executá-la.
Em relação aos processos definidos pelo PMBoK:
Figura 8 – Processos de Tempo seguidos ou não pelo projeto Fonte: Adaptado de PMBOK, 2004
Processos de Gerenciamento do Tempo
•
Definição das atividades•
Seqüenciamento das atividades•
Estimativa de recursos das atividades•
Estimativa de duração das atividades•
Desenvolvimento do cronogramaA definição das atividades a serem executadas para que fossem produzidas as diversas entregas do projeto foi realizada pelo líder do projeto através do levantamento das necessidades do cliente, porém não foram identificados os marcos do projeto e os atributos das atividades como relacionamento lógico e recursos necessários, o que prejudicou a execução dos processos seguintes.
O seqüenciamento das atividades não foi realizado de maneira correta, uma vez que o seqüenciamento mapeado no cronograma do projeto foi em função somente dos recursos alocados e não da depedência lógica existente entre as mesmas.
A estimativa de recursos das atividades não foi feita de forma correta, pois (a) somente foi levada em consideração a quantidade de recursos alocados e não a qualificação dos mesmos e (b) o recurso sênior foi alocado no calendário de recursos do projeto como “full-time” no projeto, mas na verdade era compartilhado.
A estimativa de duração das atividades não foi adequada, uma vez que (a) para a estimativa de esforço necessário para a realização das atividades o líder dividiu o esforço total do projeto pelo número de atividades mapeadas e (b) o líder do projeto também não levou em consideração a qualificação do recurso alocado à execução da atividade, que exerce significativa influência na definição da duração da mesma. O líder deveria ter utilizado a planilha de contagem de pontos por função do projeto para realizar a estimativa de duração das atividades.
A Análise de Pontos por Função (APF) é um método padronizado para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos por Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário.
A partir desta planilha, o líder seria capaz de identificar a complexidade das atividades e alocar o recurso mais adequado a cada uma delas, levando em consideração a experiência do mesmo. A partir daí, seria possível estimar o prazo necessário para execução de cada uma das atividades do projeto.
Em função do risco já identificado da equipe com pouca experiência, o líder também poderia ter incorporado um tempo de reserva ou contingência à duração de cada atividade, pontos pré-determinados do cronograma ou ao total do projeto, visando minimizar o risco de atraso das atividades, e, por conseqüência, do projeto.
O desenvolvimento do cronograma foi feito pelo líder do projeto, mas em decorrência dos erros dos processos anteriores (durações das atividades e respectivos recursos alocados) também não refletia a realidade para desenvolvimento do projeto.
Em decorrência desses problemas, o objetivo do cronograma, que é servir como uma linha de base em relação a qual o progresso do projeto possa ser acompanhado, não foi alcançado, pois este cronograma em nada refletia a realidade do projeto.
O controle do cronograma consiste em coordenar os recursos do projeto para executar as atividades planejadas, atualizar o cronograma com o progresso, detectar os desvios e promover ações corretivas quando necessário. Este processo não foi seguido pelo líder de projeto, pois o mesmo não acompanhava de forma adequada a execução das atividades. O líder se limitava a perguntar se estava tudo bem. Como a maioria dos recursos eram inexperientes, eles nem conseguiam perceber a situação em que se encontrava a atividade. Eles respondiam que estava tudo bem e o líder se satisfazia com esta resposta sem procurar buscar informações mais concretas sobre o andamento da atividade. O problema só era percebido no momento da entrega da atividade quando quase nada estava pronto.
Além disso, apesar dos constantes avisos dos recursos mais experientes de que a data estimada para a entrega do projeto não seria alcançada, o líder não tomou nenhuma atitude para reverter a situação e, ao ser questionado pelo gestor da área a respeito do progresso do projeto se limitava a responder que estava tudo bem e que o projeto seria entregue sem atraso.
O líder do projeto deveria ter monitorado de perto as atividades, principalmente as alocadas aos recursos menos experientes. Deveria ter buscado respostas mais claras em relação ao progresso das atividades para que pudesse atualizar o cronograma e desta forma identificar os desvios. Com a identificação de que o projeto estava com desvio de esforço, prazo e custo, poderia ter envolvido o gestor da área para que o mesmo apoiasse as ações corretivas necessárias ao projeto.
Outros problemas decorrentes dos erros cometidos pelo líder e descritos anteriormente (agrupados por áreas de conhecimento e mapeados na matriz “fases X áreas de conhecimento – figura 12) foram:
- Escopo: Ocorreram problemas de interfaceamento/integração entre as funcionalidades e módulos do sistema (já que no sequenciamento das atividades não foram consideradas as dependências lógicas entre as mesmas). - Tempo: O prazo de execução da maioria das atividades não estava sendo
cumprido.
- Tempo: Atraso na entrega do projeto.
- Qualidade: Reprovação do produto entregue.
3º Problema: [ QUA - INI 1 ] – Análise Crítica
“Não foi dada a devida importância ao padrão de qualidade definido pelo cliente.” Apesar do cliente ter estipulado no ínicio do projeto quais eram os padrões de qualidade desejados, o líder foi negligente e alguns desses padrões foram desprezados. Com isso no momento da entrega houve grandes problemas com relação a aceitação do produto por parte do cliente.
Em relação aos processos definidos pelo PMBoK:
Figura 9– Processos de Qualidade seguidos ou não pelo projeto Fonte: Adaptado de PMBoK, 2004
O planejamento da qualidade foi realizado uma vez que a identificação dos padrões relevantes ao projeto e a definição de como atendê-los foram mapeados.
A garantia da qualidade não foi realizada uma vez que não foi planejada e executada nenhuma atividade sistemática que garantisse que o processo de construção do produto satisfaria os padrões estabelecidos pelo cliente.
O controle da qualidade não foi realizado, uma vez que não foi executada nenhuma monitoração ao longo do projeto a fim de determinar se os produtos que estavam sendo gerados atendiam aos padrões de qualidade definidos.
O líder de projeto deveria ter divulgado para a equipe a importância e obrigatoriedade da aplicação do padrão de qualidade definido pelo cliente. Deveria ter monitorado o cumprimento do padrão através do planejamento e realização de inspeções periódicas, inspeções estas que incluiriam atividades para medir, examinar e testar os produtos gerados pelo projeto com intuito de determinar se os resultados satisfaziam aos padrões de qualidade estabelecidos pelo cliente.
As conseqüências decorrentes dos erros cometidos pelo líder e descritos anteriormente (agrupados por áreas de conhecimento e mapeados na matriz “fases X áreas de conhecimento” – figura 12) foram:
Processos da Qualidade
•Planejamento da Qualidade
•
Realizar a garantia da qualidade- Qualidade: Insatisfação quanto à qualidade do produto por não atender aos padrões estabelecidos.
- Tempo: Atraso na entrega do projeto. O projeto que já sofreu atraso devido aos outros problemas já tratados, após a entrega precisou ser extendido devido ao retrabalho decorrente do não atendimento aos padrões do projeto e conseqüênte reprovação por parte do cliente.
- Custo: O custo real do projeto ultrapassou o estimado. A necessidade de manter a equipe alocada para adequação aos padrões contribuiu para o desvio do orçamento planejado.
Em função dos erros cometidos pelo líder, o projeto sofreu um atraso de aproximadamente 10 meses e elevou o custo em cerca de 80% do previsto.