O documento discute três ações que podem reduzir falhas em projetos de desenvolvimento de sistemas: (1) melhorar a gestão da informação através da comunicação eficaz com as partes interessadas, (2) implementar uma gestão de riscos estruturada para identificar e mitigar riscos potenciais, e (3) estabelecer um processo rigoroso de gestão de requisitos para assegurar que os requisitos capturados sejam completos e alinhados com os objetivos do projeto.

1. SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL
PÓS-GRADUAÇÃO EM GESTÃO E GOVERNANÇA DE TI
FATORES QUE PODEM REDUZIR
FALHAS EM PROJETOS.
AUTOR
Lucas Pereira Dos Santos
Betim
2014

2. SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL
AUTOR
Lucas Pereira dos Santos
Fatores que podem reduzir falhas em projetos.
Projeto apresentado para avaliação na
disciplina desenho e desenvolvimento de
sistemas de informação, Pós-graduação, na
faculdade SENAC
Professor: Dirceu Matheus Junior
BETIM
2014

3. SUMÁRIO
INTRODUÇÃO ..................................................................................................................................... 4
DESENVOLVIMENTO........................................................................................................................... 4
AÇÕES QUE PODEM REDUZIR A POSSIBILIDADE DE FALHAS............................................................ 6
GESTÃO DA INFORMAÇÃO ........................................................................................................ 6
GESTÃO DE RISCOS.................................................................................................................... 8
GESTÃO DE REQUISITOS ............................................................................................................ 9
CONCLUSÃO ......................................................................................................................................11

4. INTRODUÇÃO
Gestão de projetos é uma área muito importante em diversos segmentos de mercado.
Devido ao alto nível de concorrência entre as empresas, uma gestão de projetos eficiente
garantirá uma vantagem competitiva considerável. Isso porque, um bom gerenciamento de
projetos promove melhorias em todo o processo que envolve o projeto, o que garante que
metas, prazos e expectativas sejam atingidos.
Porém, varias pesquisas apontam que a maioria dos projetos é entregue com falhas,
são entregues fora do prazo e custando bem mais que o planejado. Segundo a IBM
(International Business Machines Corporation) apenas 40% dos projetos cumprem as metas
de cronograma, orçamento e qualidade.
Dentre os fatores de fracasso, podemos destacar: requisitos incompletos; falta de
envolvimento do usuário; falta de recursos; expectativas não realistas; falta de apoio
executivo; mudanças de requisitos; falta de planejamento; falta de gestão da TI e
analfabetismo tecnológico.
Com base nessas informações pretende-se relacionar três ações que podem ser usadas
para reduzir a possibilidade de falha em um projeto de desenvolvimento de sistema.
DESENVOLVIMENTO
Projetos podem sair do controle por vários fatores, vamos analisar alguns possíveis
fatores que podem levar a isso:
 Não conseguir entender a real necessidade do cliente
 Pela falta de documentação, que poderia dar um foco mais detalhado ao
desenvolvimento.
 Os objetivos do projeto podem não estar alinhados com os objetivos de negócios e
estratégicos da organização, com isso organização e projeto não “caminhariam”
juntos.
 Coordenação inadequada, que pode desalinhar os projetos e potencialmente gerar
conflitos.
 Incapacidade de estabelecer uma liderança eficaz nos domínios de negócio, técnica e
organizacional.
 Não conseguir identificar nem envolver as partes interessadas
 Aplicação inadequada da Gestão de mudanças
 Comunicação Inadequada entre os envolvidos no projeto
 Papéis e responsabilidade não claras
 Equipe inexperiente
 Práticas que minam a motivação da equipe
 Requisitos do projeto são escritos com base no pressuposto de que tudo vai funcionar
como planejado. Enquanto lidar com os problemas na maioria das vezes não é
planejado
 Falta de pensar no futuro, para prever e resolver possíveis problemas.

5. Dentre vários outros fatores que podem influenciar no sucesso no projeto. O que fica claro
é que na maior parte dos casos, as falhas estão relacionadas a um conjunto de fatores.
Podemos dividir em tópicos as áreas ou etapas mais sensíveis a falhas:
 Liderança e Governança
 Stakeholders
 Equipe de desenvolvimento
 Requisitos
 Estimativas
 Planejamento
 Gestão de riscos
 Arquitetura e design da solução
 Gestão da Informação
 Gestão da Qualidade
 Gestão do Projeto
 Tomadas de decisão
 Processos
Vamos tomar esses tópicos como exemplo e analisá-los no diagrama de Ishikawa:
Podemos perceber como as áreas estão interligadas e que o sucesso de uma área não garante
um projeto dentro das expectativas. É importante uma harmonia entre todas as áreas a fim de
garantir um produto final de qualidade dentro do que foi planejado.
Com o diagrama fica claro que um projeto falho pode ser ocasionado por um, ou vários erros
provenientes de uma má estimativa, uma liderança ineficiente, equipamentos inadequados,
processos mau definidos, dentre outros. Se o projeto fracassou, provavelmente ocorreram
falhas em uma das etapas listadas acima. Em nosso diagrama a intenção é mostrar etapas e
áreas que podem gerar um projeto falho se não forem bem gerenciadas.

6. AÇÕES QUE PODEM REDUZIR A POSSIBILIDADE DE FALHAS
GESTÃO DA INFORMAÇÃO
Tão importante quanto qualquer atividade nas empresas, a comunicação eficaz é um
fator determinante para o sucesso de um projeto. Os gestores gastam boa parte do seu tempo
com comunicação ou com problemas vindos desse processo.
Reconhecer a comunicação como um processo importante, conhecendo suas
características, elementos e partes interessadas é o primeiro passo para um gerenciamento de
projetos eficiente.
Registrar muitos dados sobre o projeto não garante sucesso, afinal podemos ficar
perdidos no meio de tantas informações sem saber como usá-las. Outro agravante seria o fato
das pessoas acharem que se comunicam bem, quando na verdade o receptor muitas vezes
interpreta a mensagem o que pode comprometer o projeto.
Segundo o PMBOK:
“O processo Planejamento das Comunicações determina as necessidades de
informações e comunicações das partes interessadas; por exemplo, quem
precisa de qual informação, quando precisarão dela, como ela será fornecida
e por quem. Embora todos os projetos compartilhem a necessidade de
comunicar as informações sobre o projeto, as necessidades de informações e
os métodos de distribuição variam muito. Um fator importante para o
sucesso do projeto é identificar as necessidades de informações das partes
interessadas e determinar uma maneira adequada para atender a essas
necessidades.”[...]“O planejamento das comunicações está, muitas vezes,
estreitamente ligado aos fatores ambientais da empresa e às influências
organizacionais, pois a estrutura organizacional do projeto terá um efeito
importante nos requisitos de comunicações do projeto.”(PMBOK, PROJECT
MANAGEMENT INSTITUTE, 2004, p.225).
A comunicação pode ocorrer de varias formas, pode ser verbal ou não-verbal, formal
ou informal. O que fica claro é que a quantidade de informação não é um diferencial e sim a
forma com que a organização trata essas informações durante todo o projeto.
Sendo assim, a primeira ação que pode ser tomada para minimizar falhas em projetos,
é entender que a informação é um ativo do projeto e precisa ser gerenciada da melhor maneira
possível. É importante mapear todas as partes interessadas no projeto, compartilhar as
informações com as pessoas certas no momento certo, com clareza e sem ambiguidade. Criar
processos que monitorem se a comunicação e a gestão da informação estão sendo realizados
como o planejado.
Ações complementares:
 Geração periódica de relatórios (em formato informativo, em encontros e por e-
mail) sobre o andamento do projeto para cada uma das partes interessadas.
Assim toda equipe estaria a par de todos os acontecimentos.
 Criar um painel com diagramas e formas que mostre o progresso do projeto em
tempo real (Dashboard) . Sendo o painel acessível às partes interessadas (de
forma física e logica).

7.  A comunicação preferencialmente será realizada pessoalmente ou por vídeo
conferencia. A fim de passar mais confiança para os clientes e aproximar os
interessados com o projeto.
 Classificar as partes interessadas no projeto e fim de disponibilizar a
informação certa, para a pessoa certa, no momento certo.
 Garantir que um processo não inicie antes da aprovação formal (por escrito) da
parte interessada, o que garantirá que todos estão cientes do que será realizado
no projeto e que concordam com as ações.
Concluo dizendo, que todas as ações visando a melhora na comunicação devem ser
realizadas baseando-se em conhecimentos de processos anteriores da empresa e com o auxilio
de guias e ferramentas como, por exemplo, o guia PMBOK (Project Management Body of
Knowledge), pois contém tópicos específicos sobre o gerenciamento das comunicações em
projetos elaborado por profissionais experientes, o que nos dá embasamento para afirmar que
as ações vão melhorar a qualidade do projeto.

8. GESTÃO DE RISCOS
Planejar como reagir a um problema ou ameaça antes que ela aconteça, isso pode
definir gestão de riscos. Parece óbvia a sua importância, mais mesmo assim em muitos
projetos essa gestão é deixada em segundo plano.
A gestão de risco reduz a probabilidade de fracasso do projeto, seja ele financeiro, de
cronograma ou no desempenho. Segundo o Project Management Institute (PMI), projetos com
uma boa gestão de risco têm 15% a mais de chances de obter sucesso do que projetos sem
gestão de risco. (PMI Risk symposium 2005) as conclusões foram que uma boa gestão de
risco pode oferecer:
 Diminui custos em 17%.
 Aumento de 15% da eficiência do cronograma.
 Um único risco evitado pode pagar todo o gerenciamento de risco.
Podemos perceber que gerenciando os riscos o gerente de projetos pode planejar e estar um
passo a frente de uma futura ameaça, fator que pode garantir o sucesso de uma empreitada.
Ações que seriam tomadas para aplicar uma boa gestão de riscos:
Criar uma comissão responsável pela gestão de risco, para que sejam levantados os principais
riscos do projeto. Com dos dados em mãos haveria um processo para avaliar qual o impacto
das ameaças no projeto e assim qual a melhor ação para minimizá-las. Podendo ser a ameaça
prevenida, reduzida a um nível aceitável de risco, ou até transferida a responsabilidade para
uma empresa terceira (baseado nas praticas recomendadas pelo PMBOK).
Principais ações que seriam tomadas:
 Fazer da gestão de risco parte do projeto
 Identificar os riscos no início do projeto. Uma comissão deve ser criada para
esse fim.
 Comunicar sobre os riscos a todos os interessados
 Considerar riscos como ameaças ou oportunidade conforme a situação
 Atribuir responsabilidades, deixar claro quem é responsável por cada risco.
 Criar processos que priorizam os Riscos conforme regras e necessidade da
empresa.
 Criar métodos para analisar bem os riscos e tomar a melhor decisão para
minimizá-lo. Baseado em guias ou experiências anteriores.
 Registrar todos os acontecimentos para formação de uma boa base de
conhecimentos que poderá ser usada em outros projetos da empresa.
Para concluir, é importante a criação ou adoção de uma metodologia para controlar os
riscos do projeto. Nossa segunda ação seria implantar uma gestão de riscos eficiente e
monitorada, e fim de controlar futuras ameaças ao projeto.

9. GESTÃO DE REQUISITOS
Cada nova atividade, cada novo produto, cada novo projeto são criados em resposta a
uma necessidade de negócio. No entanto, muitas vezes, nos encontramos em situações em
que, apesar de gastar um enorme tempo e recursos, há um descompasso entre o que foi
projetado e o que é realmente era necessário.
Quando devidamente implementada e apoiada, permite superar as expectativas das
partes interessadas, melhorar o desempenho, satisfazer os benefícios esperados do projeto e
alcançar resultados comerciais tangíveis.
Má gestão de requisitos é uma das principais causas de fracasso do projeto
(PMI 2014 Pulse of the Profession® study)
A má gestão de requisitos pode acontecer tanto por parte da equipe de projetos, quanto por
parte do cliente que pode estar desinteressado. É importante a criação de ações que garantam uma boa
analise de requisitos, nossa terceira ação, seria a criação de um processo bem definido para descobrir,
analisar e documentar os requisitos que estão relacionados com os objetivos do negocio.
Analise de requisitos pode causar muitos problemas, vale lembrar que essa analise é
responsável por definir de forma clara e precisa o escopo do projeto, para que se possa avaliar o tempo
e os recursos necessários para completa-lo. Uma analise incompleta poderá comprometer o sucesso do
projeto.
Ações para melhorar a Analise de requisitos que consequentemente reduzir as falhas:
 Utilizando-se das melhores praticas e recomendações da equipe de gestão da informação,
garantir uma comunicação eficaz entre equipe e cliente.
 Antes de iniciar o projeto, reunir-se com todos os envolvido no projeto para apresentação e
identificação das partes interessadas. Objetivo: identificar cada um dos stakeholders, entender
suas necessidades e expectativas.
 Conforme os dados coletados, classificar cada stakeholder de acordo com os seguintes
tópicos:
o Dependência: nível de dependência do stakeholder em relação à organização. A
dependência pode ser em relação a recursos financeiros (salários, investimentos,
pagamentos, doações e afins) ou não financeiros (insumos, trabalho, produtos,
serviços).
o Impacto: grau de alteração sofrida pelo stakeholder por atividades e ações da
organização. As alterações podem ser no meio físico ou social.
o Influência: grau de interferência que o stakeholder pode exercer na tomada de decisão
ou no andamento do projeto, sem necessariamente ter poder formal para tanto.
o Poder: domínio de responsabilidade formal (legal, financeira, governança e/ou
operacional) estabelecido por meio de normas, contratos, políticas ou outros
documentos normativos.
o Proximidade da relação: grau de proximidade do stakeholderem relação à
organização. Inclui stakeholders internos (empregados diretos e indiretos) e externos
(parceiros, fornecedores, governo e aqueles que vivem próximo aos locais de
produção).
o Urgência ou Tensão: grau de urgência e tensão do stakeholder em relação a uma
situação específica.

10. o Representação: stakeholders que se apresentam com legitimidade para representar o
interesse ou a voz de um grupo impossibilitado de se expressar diretamente, como
futuras gerações ou meio ambiente.
o Ponto de vista diferenciado: Aquele stakeholder que pode trazer um ponto de vista
menos conhecido, normalmente pelo perfil pessoal, mas também pelo contexto que
vivencia.
Sendo critérios adicionados ou excluídos conforme o tipo de projetos. O mais importante é
entendes que são as partes interessadas e a participação que ela tem no projeto.
 Depois que estiverem claro todos os interessados no projeto, bem como seu perfil e
tipo de participação, será definido como a equipe deve interagir com cada grupo de
stakeholders conforme suas características:
Figura 1: AA1000 Stakeholder Engagement Standard (AA1000SES)

11.  Depois de conversar e classificar as partes interessadas, reuniões mais focadas serão
realizadas com cada grupo, sendo importante ouvir e classificar todos os requisitos
listados pelos clientes:
o Requisitos Funcionais - Estes definem como um / serviço / produto solução
deve funcionar a partir da perspectiva do usuário final.
o Requisitos Operacionais - Estes definem as operações que devem ser levadas
a cabo no fundo para manter o funcionamento do produto ou do processo
durante um período de tempo.
o Requisitos Técnicos - Estes definem as questões técnicas que devem ser
considerados para implementar com sucesso o processo ou criar o produto.
o Requisitos de transição - Estes são os passos necessários para implementar o
novo produto ou processo sem problemas.
 E por fim, ter sempre um acordo assinado das partes interessadas, até mesmo de
reuniões (ata), dizendo que os requisitos ali apresentados refletem as suas
necessidades atuais. O Desenvolvimento não deve iniciar antes desse acordo, que por
sua vez precisa ser claro e objetivo.
CONCLUSÃO
O guia PMBOK (Project Management Body of Knowledge), um conjunto com as
melhores praticas para gestão de Projetos, inclui guias para as mais diversas etapas do projeto,
ficou claro durante o desenvolvimento do trabalho que já existem diversos guias e
metodologias para minimizarem as falhas dos projetos.
O jargão “quem faz a empresa são as pessoas” se encaixa perfeitamente em nosso
trabalho, pois é muito importante ter pessoas motivadas e interessadas para que o projeto
aconteça da melhor forma possível, é importante uma mente aberta para novas metodologias,
que podem ser o diferencial entre o sucesso e o fracasso em uma empreitada.
Sendo assim, concluímos que todos os envolvidos no projeto precisam estar motivados
e com normas e procedimentos bem definidos pelos gestores, que por sua vez também
precisam estar engajados com o projeto para criação e fiscalização de mecanismos que
reduzam as falhas e mantenha a equipe alinhada.